Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
only_export_decoder_api.patch | Only export symbols defined in the decoder API. The encoder API is not final yet, so upstream exports all symbols to make development easier. For packaging we only want to expose the public API. |
Joachim Bauch <bauch@struktur.de> | no | |||
disable_tools.patch | Disable building of some internal tools that no longer link because internal symbols are no longer exported. | Joachim Bauch <bauch@struktur.de> | no | |||
reject_reference_pics_from_different_sps.patch | [PATCH] Try to mitigate asan failures. See #345 for my analysis and details (This PR is just for discussion.) (The CVE references are obtained from the Debian security tracker, which links the issues.) This makes the following POCs stop failing: - poc3 (#337) - poc7-1 (#341) CVE-2022-43239 (note: does NOT fix poc7-2) - poc8-2, poc8-3, poc8-4 (#342) CVE-2022-43244 (note: does NOT fix poc8-1) - poc11-1, poc11-2 (#345) CVE-2022-43249 - poc12 (#346) - poc13 (#347) CVE-2022-43252 - poc16 (#350) |
Tobias Frost <tobi@debian.org> | no | https://github.com/strukturag/libde265/pull/365 | 2022-12-12 | |
use_sps_from_the_image.patch | [PATCH] Use the sps from the image (as e.g mc_chroma is using the sps to determine picture properties, like pic_width_in_luma_samples and pic_height_in_luma_samples, I *think* this is more correct. This PR is for discussion. (See #345.) It makes the failures go away, but that does not mean it's correct :) The following poc will be stop failing if (only) this patch is applied: - poc2 #336 - CVE-2022-43238 - poc4 #338 - CVE-2022-43241 - poc6-1, poc6-2 #340 - CVE-2022-43242 - poc7-1, poc7-2 #341 - CVE-2022-43239 - poc8-1 #342 - CVE-2022-43244 - poc9-3 #343 - CVE-2022-43236 - poc10-2, poc10-3 #344 - CVE-2022-43237 - poc16 #350 - poc19 #353 The following are still failing if only this patch is applied, but they stop failing if #365 is applied as well, but will still fail with ONLY #365 applied (IOW, both are needed) - poc1 #335 - CVE-2022-43240 - poc3 #337 - CVE-2022-43235 - poc5 #339 - CVE-2022-43423 - poc9-1,poc9-2, poc9-4 #343 - CVE-2022-43236 - poc14 #348 - CVE-2022-43253 - poc15 #349 - CVE-2022-43248 - poc17-1, poc17-2 #351 - poc18 #352 - CVE-2022-43245 |
Tobias Frost <tobi@debian.org> | no | https://github.com/strukturag/libde265/pull/366 | 2022-12-12 | |
recycle_sps_if_possible.patch | [PATCH] Don't update sps if they are only repeated This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345: > One way would be just to look at the pointers of the SPS (fast and easy, but > may reject more than required), or investigate if the SPS used for the image > generations are "compatible". This changes do exactly this: It (very conservativly) checks if the old and new sps have identical information -- except the reference picture set, which I believe is supposed to be updated by new sps'). If they are basically identical, the old sps will be used instead of the new one, (of course, reference image set is updated from the new one) I'm using standalone operator== and helper functions to avoid changing ABI of the library; if an ABI bump would be done, of course this should go to the respective classes. |
Tobias Frost <tobi@debian.org> | no | https://github.com/strukturag/libde265/pull/372 | 2023-01-13 | |
CVE-2023-27102.patch | commit 0b1752abff97cb542941d317a0d18aa50cb199b1 check whether referenced PPS exists (fixes #393) =================================================================== |
Dirk Farin <dirk.farin@gmail.com> | no | 2023-03-04 | ||
CVE-2023-27103.patch | commit d6bf73e765b7a23627bfd7a8645c143fd9097995 check for valid slice header index access (fixes #394) =================================================================== |
Dirk Farin <dirk.farin@gmail.com> | no | 2023-03-04 | ||
CVE-2023-43887.patch | commit 63b596c915977f038eafd7647d1db25488a8c133 fix #418 =================================================================== |
Dirk Farin <dirk.farin@gmail.com> | no | 2023-09-01 | ||
CVE-2023-47471.patch | commit e36b4a1b0bafa53df47514c419d5be3e8916ebc7 null-pointer check in debug output (fixes #426) diff --git a/libde265/slice.cc b/libde265/slice.cc index 280b7417..435123dc 100644 |
Dirk Farin <dirk.farin@gmail.com> | no | 2023-11-04 | ||
CVE-2023-49465.patch | commit 1475c7d2f0a6dc35c27e18abc4db9679bfd32568 possible fix for #435 =================================================================== |
Dirk Farin <dirk.farin@gmail.com> | no | 2023-11-23 | ||
CVE-2023-49467.patch | commit 7e4faf254bbd2e52b0f216cb987573a2cce97b54 prevent endless loop for #434 input diff --git a/libde265/slice.cc b/libde265/slice.cc index 435123dc..3a8a8de1 100644 |
Dirk Farin <dirk.farin@gmail.com> | no | 2023-11-23 | ||
CVE-2023-49468.patch | commit 3e822a3ccf88df1380b165d6ce5a00494a27ceeb fix #432 (undefined IPM) diff --git a/libde265/image.h b/libde265/image.h index 0b536054..0a0c0e32 100644 |
Dirk Farin <dirk.farin@gmail.com> | no | 2023-11-23 |