Closed Bug 1823614 Opened 2 years ago Closed 2 years ago

limit the number of scans we allow in jpeg images to some finite value

Categories

(Core :: Graphics: ImageLib, defect)

defect

Tracking

()

RESOLVED FIXED
113 Branch
Tracking Status
firefox113 --- fixed

People

(Reporter: tnikkel, Assigned: tnikkel)

References

Details

Attachments

(1 file)

No description provided.
Severity: -- → S3
See Also: → 1252200
See Also: → 1252196

Bug 1252200 and bug 1252196 talk about this problem more. However using the programs there to generate a testcase jpeg it did not seem to have a large number of scans, either that or I wasn't patient enough to wait for the first few scans to complete, so I'm filing this separately.

We want to provide some finite limit to prevent small jpeg files from being able to tie up cpus for a much larger time than their small size would normally allow. We want to choose a number high enough so that no sane jpeg file would approach it, unless it had been crafted to take advantage of this problem.

Skia's jpeg decoder limit's it to 100:

https://searchfox.org/mozilla-central/rev/f078cd02746b29652c134b144f0629d47e378166/gfx/skia/skia/src/codec/SkJpegDecoderMgr.cpp#33

The OSS_Fuzz targets for libjpeg-turbo limit it to 500:

https://bugzilla.mozilla.org/show_bug.cgi?id=1252196#c11

Depends on D173119

Pushed by tnikkel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9e5254e7728e Limit the number of scans we allow in jpeg images to some finite value. r=gfx-reviewers,bradwerth

Backed out for causing reftest failures on pattern-transformed.

Flags: needinfo?(tnikkel)

I'm not sure this could cause those failures. There is no jpegs in those tests.

Flags: needinfo?(tnikkel)

There is something strange going on. I first backed out Bug 1824025 but I did the backout before seeing this backfills that is why I re-landed bug 1824025 and backed out this bug. Most likely I will re-land your patch.

Flags: needinfo?(tnikkel)
Pushed by imoraru@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/12d26e785e81 Limit the number of scans we allow in jpeg images to some finite value. r=gfx-reviewers,bradwerth a=reland

Sorry for any inconvenience caused by this. Your patch was re-landed.

(In reply to Iulian Moraru from comment #6)

There is something strange going on. I first backed out Bug 1824025 but I did the backout before seeing this backfills that is why I re-landed bug 1824025 and backed out this bug. Most likely I will re-land your patch.

Ah, I see. In the backfills link if I open the full log of an Rs2 run on the push for bug 1824025 then I do not see the pattern-transformed* tests as being run, so they must have moved chunks unexpectedly?

Flags: needinfo?(tnikkel)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 113 Branch
Regressions: 1824565
No longer regressions: 1824565

Stumbled upon the max scans that imagemagick allows so figured I'd record it here for posterity: 1024

https://github.com/ImageMagick/ImageMagick/blob/f7b5682435d37ad5ea8142d69629c93228e6376d/coders/jpeg.c#L112

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: