Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
debian-changes | debian-changes The Debian packaging of aom is maintained in git, using the merging workflow described in dgit-maint-merge(7). There isn't a patch queue that can be represented as a quilt series. A detailed breakdown of the changes is available from their canonical representation - git commits in the packaging repository. For example, to see the changes made by the Debian maintainer in the first upload of upstream version 1.2.3, you could use: % git clone https://git.dgit.debian.org/aom % cd aom % git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian' (If you have dgit, use `dgit clone aom`, rather than plain `git clone`.) A single combined diff, containing all the changes, follows. |
Debian Multimedia Maintainers <debian-multimedia@lists.debian.org> | no | 2023-08-27 | ||
CVE-2021-30473.patch | CVE-2021-30473 | Markus Koschany <apo@debian.org> | no | https://aomedia.googlesource.com/aom/+/d0cac70b542c38accd916f8afd13592d34c48963%5E%21/ | 2023-08-28 | |
CVE-2021-30474.patch | CVE-2021-30474 | Markus Koschany <apo@debian.org> | no | https://aomedia.googlesource.com/aom/+/6e31957b6dc62dbc7d1bb70cd84902dd14c4bf2e%5E%21/ | 2023-08-29 | |
CVE-2021-30475.patch | CVE-2021-30475 | Markus Koschany <apo@debian.org> | no | https://aomedia.googlesource.com/aom/+/12adc723acf02633595a4d8da8345742729f46c0%5E%21/ | 2023-08-29 | |
CVE-2020-36131.patch | CVE-2020-36131 This is also the fix for CVE-2020-36135. |
Markus Koschany <apo@debian.org> | no | 2023-08-29 | ||
CVE-2020-36133.patch | CVE-2020-36133 | Markus Koschany <apo@debian.org> | no | https://aomedia.googlesource.com/aom/+/5c9bc4181071684d157fc47c736acf6c69a85d85 | 2023-08-29 | |
CVE-2020-36130.patch | CVE-2020-36130 | Markus Koschany <apo@debian.org> | no | https://aomedia.googlesource.com/aom/+/be4ee75fd762d361d0679cc892e4c74af8140093%5E%21/#F0 | 2023-09-02 | |
0001-Do-not-account-for-high-bit-depth-twice.patch | Do not account for high bit depth twice. When calculating the stride (for packed formats) and alloc_size, we should not account for high bit depth twice. bps accounts for high bit depth (implicitly). stride_in_bytes also accounts for high bit depth. So any value calculated by multiplying bps and stride_in_bytes ends up accounting for high bit depth twice. A solution is to divide bps not by a fixed 8 bits but by a variable (bit_depth) that is either 8 bits or 16 bits depending on the bit depth. |
Wan-Teh Chang <wtc@google.com> | no | 2019-06-28 | ||
0002-Fix-integer-overflows-in-calc-of-stride_in_bytes.patch | Fix integer overflows in calc of stride_in_bytes Fix unsigned integer overflows in the calculation of stride_in_bytes in img_alloc_helper() when d_w is huge. Change the type of stride_in_bytes from unsigned int to int because it will be assigned to img->stride[AOM_PLANE_Y], which is of the int type. Test: cmake ../aom -G Ninja -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Debug \ -DSANITIZE=unsigned-integer-overflow ninja ./test_libaom --gtest_filter=AomImageTest.AomImgAllocHugeWidth (cherry picked from commit 7aa2edc2b09f98c32820923d813fd73eb23b5861) |
Wan-Teh Chang <wtc@google.com> | no | upstream | 2024-04-03 | |
0003-Avoid-integer-overflows-in-align_image_dimension.patch | Avoid integer overflows in align_image_dimension() Impose maximum values on the input parameters so that we can perform arithmetic operations without worrying about overflows. Fix a bug (introduced in commit 7aa2edc) that the ~ operator is applied to (stride_align - 1), which is unsigned int, and then the result is converted to uint64_t. Also change the AomImageTest.AomImgAllocHugeWidth test to write to the first and last samples in the first row of the Y plane, so that the test will crash if there is unsigned integer overflow in the calculation of stride_in_bytes. (cherry picked from commit 60653dff7f8ee3e769a0aeec5e210a4fc2687717) |
Wan-Teh Chang <wtc@google.com> | no | upstream | 2024-04-04 | |
0004-Apply-stride_align-to-byte-count-not-pixel-count.patch | Apply stride_align to byte count, not pixel count stride_align is documented to be the "alignment, in bytes, of each row in the image (stride)." (cherry picked from commit a38ab61907e7619c6b100a769284505959def53e) |
Wan-Teh Chang <wtc@google.com> | no | 2024-04-08 |