Merge version 1.0.15-1+rpi1+deb13u1 and 1.0.15-1+deb13u2 to produce 1.0.15-1+rpi1+deb13u2

Merge version 1.0.15-1+rpi1 and 1.0.15-1+deb13u1 to produce 1.0.15-1+rpi1+deb13u1

Merge libde265 (1.0.15-1+deb13u2) import into refs/heads/workingbranch

[PATCH] fix reallocation of metadata array when ctb size changes (thanks to Ana K.)

Gbp-Pq: Name CVE-2026-33164_CVE-2026-33165.patch

CVE-2026-54240, CVE-2026-54241: fix pixel-accessor integer overflow

Origin: upstream, https://github.com/strukturag/libde265/commit/bdca87569b9c63c2a7054d90ae4462dbb78d159a
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-ccfw-29x7-rrx3
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-j2qq-x2xq-g9wr
Applied-Upstream: 1.1.1

The image pixel accessors computed xpos + ypos*stride in signed 32-bit
arithmetic; frames with width*height > INT32_MAX wrap the offset and the
returned pointer lands far outside the buffer (OOB read/write). Widen
stride/offset math to 64 bits and store validated SPS dimensions in
uint16_t.

Gbp-Pq: Name CVE-2026-54240_CVE-2026-54241.patch

CVE-2026-49346: fix integer overflow in image plane allocation size

Origin: upstream, https://github.com/strukturag/libde265/commit/8a1b5cf212f78e1c77cb46eb5d56e492a9336eb8
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-vv8h-932h-7r86
Bug-Debian: https://bugs.debian.org/1140431
Applied-Upstream: 1.1.0

Large SPS dimensions with 16-bit bit depth overflow the 32-bit allocation
size in de265_image_get_buffer(); the wrapped ~1 KB allocation is later
written with the full plane size, corrupting the heap.

Gbp-Pq: Name CVE-2026-49346.patch

CVE-2026-49295: bound aggregate short-term RPS size

Origin: upstream, https://github.com/strukturag/libde265/commit/691f3a3c55b3d32478c4a49895dee061a282652b
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-g2rg-wj66-w594
Bug-Debian: https://bugs.debian.org/1140431
Applied-Upstream: 1.1.0

Missing aggregate bound check on predicted reference picture set entries
allows exceeding the 16-entry array, an out-of-bounds array write in
process_reference_picture_set().

Gbp-Pq: Name CVE-2026-49295.patch

CVE-2026-49337: free orphaned slice header when no active image unit

Origin: upstream, https://github.com/strukturag/libde265/commit/683cb9fa603e35840642f98765ab95cdb71cadf9
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-g5hj-rf9f-7vxm
Bug-Debian: https://bugs.debian.org/1140431
Applied-Upstream: 1.1.0
Comment: Backport: on 1.0.15 the pre-existing unconditional add_slice_segment_header() call must be removed (upstream moves it into the guarded block); keeping both would double-free every slice header.

Slice headers attached to finished pictures without an active image unit
were retained forever; a crafted NAL sequence can grow memory without
bound during continuous streaming.

Gbp-Pq: Name CVE-2026-49337.patch

CVE-2026-45383: prevent reading past end of CtbAddrRStoTS[] in WPP images

Origin: upstream, https://github.com/strukturag/libde265/commit/d1a2c3b4b751d21f44e8e82220fe9766c9d116ff
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-wg9q-ppqw-6q38
Applied-Upstream: 1.0.19

In the WPP slice decoder ctbAddrRS = ctbRow * ctbsWidth can exceed the
allocated vector size, causing out-of-bounds reads.

Gbp-Pq: Name CVE-2026-45383.patch

CVE-2026-45382: fix CTB OOB access when pps.sps mismatches active sps

Origin: upstream, https://github.com/strukturag/libde265/commit/c33b4f63ae9056b00f34a31874fed55cd0aa29c9
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-hwhx-x2mq-ccr9
Applied-Upstream: 1.0.19

Malformed PPS data creates an out-of-bounds index into the CtbAddrRStoTS
array, causing a heap-buffer-overflow read in decode_slice_unit_tiles.

Gbp-Pq: Name CVE-2026-45382.patch

CVE-2024-38949, CVE-2024-38950: fix SDL OOB in dec265 display path

Origin: upstream, https://github.com/strukturag/libde265/commit/4089de0845e0009e019be4ca5cbebaf2aee0a8ce
Bug: https://github.com/strukturag/libde265/issues/460
Bug-Debian: https://bugs.debian.org/1074416
Applied-Upstream: 1.0.19

Heap buffer overflow in the dec265 SDL output on 4:4:4 streams
(display444as420) and on mid-stream resolution changes.

Gbp-Pq: Name CVE-2024-38949_CVE-2024-38950.patch

CVE-2025-61147: check for valid integer command line parameters

Origin: upstream, https://github.com/strukturag/libde265/commit/8b17e0930f77db07f55e0b89399a8f054ddbecf7
Bug: https://github.com/strukturag/libde265/issues/484
Bug-Debian: https://bugs.debian.org/1129257
Applied-Upstream: 1.0.18

Invalid numeric arguments (e.g. for --framedrop) made dec265 crash with a
segmentation fault in decoder_context::compute_framedrop_table().

Gbp-Pq: Name CVE-2025-61147.patch

[PATCH] Fix missing "LIBS_PRIVATE" for libde265.pc in autoconf builds.

From 56d1cf52e43d734692721c99b72815c0fee1f184 Mon Sep 17 00:00:00 2001
Forwarded: https://github.com/strukturag/libde265/pull/439

Forwarded: https://github.com/strukturag/libde265/pull/439
Gbp-Pq: Name fix-private-libs-pc.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.

Gbp-Pq: Name recycle_sps_if_possible.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

Gbp-Pq: Name use_sps_from_the_image.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)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.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.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.15-1+deb13u2) trixie-security; urgency=medium

  * CVE-2026-33164 (Closes: #1131469)
  * CVE-2026-33165 (Closes: #1131468)

[dgit import unpatched libde265 1.0.15-1+deb13u2]

Import libde265_1.0.15-1+deb13u2.debian.tar.xz

[dgit import tarball libde265 1.0.15-1+deb13u2 libde265_1.0.15-1+deb13u2.debian.tar.xz]

Merge libde265 (1.0.15-1+deb13u1) import into refs/heads/workingbranch

CVE-2026-54240, CVE-2026-54241: fix pixel-accessor integer overflow

Origin: upstream, https://github.com/strukturag/libde265/commit/bdca87569b9c63c2a7054d90ae4462dbb78d159a
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-ccfw-29x7-rrx3
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-j2qq-x2xq-g9wr
Applied-Upstream: 1.1.1

The image pixel accessors computed xpos + ypos*stride in signed 32-bit
arithmetic; frames with width*height > INT32_MAX wrap the offset and the
returned pointer lands far outside the buffer (OOB read/write). Widen
stride/offset math to 64 bits and store validated SPS dimensions in
uint16_t.

Gbp-Pq: Name CVE-2026-54240_CVE-2026-54241.patch

CVE-2026-49346: fix integer overflow in image plane allocation size

Origin: upstream, https://github.com/strukturag/libde265/commit/8a1b5cf212f78e1c77cb46eb5d56e492a9336eb8
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-vv8h-932h-7r86
Bug-Debian: https://bugs.debian.org/1140431
Applied-Upstream: 1.1.0

Large SPS dimensions with 16-bit bit depth overflow the 32-bit allocation
size in de265_image_get_buffer(); the wrapped ~1 KB allocation is later
written with the full plane size, corrupting the heap.

Gbp-Pq: Name CVE-2026-49346.patch

CVE-2026-49295: bound aggregate short-term RPS size

Origin: upstream, https://github.com/strukturag/libde265/commit/691f3a3c55b3d32478c4a49895dee061a282652b
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-g2rg-wj66-w594
Bug-Debian: https://bugs.debian.org/1140431
Applied-Upstream: 1.1.0

Missing aggregate bound check on predicted reference picture set entries
allows exceeding the 16-entry array, an out-of-bounds array write in
process_reference_picture_set().

Gbp-Pq: Name CVE-2026-49295.patch

CVE-2026-49337: free orphaned slice header when no active image unit

Origin: upstream, https://github.com/strukturag/libde265/commit/683cb9fa603e35840642f98765ab95cdb71cadf9
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-g5hj-rf9f-7vxm
Bug-Debian: https://bugs.debian.org/1140431
Applied-Upstream: 1.1.0
Comment: Backport: on 1.0.15 the pre-existing unconditional add_slice_segment_header() call must be removed (upstream moves it into the guarded block); keeping both would double-free every slice header.

Slice headers attached to finished pictures without an active image unit
were retained forever; a crafted NAL sequence can grow memory without
bound during continuous streaming.

Gbp-Pq: Name CVE-2026-49337.patch

CVE-2026-45383: prevent reading past end of CtbAddrRStoTS[] in WPP images

Origin: upstream, https://github.com/strukturag/libde265/commit/d1a2c3b4b751d21f44e8e82220fe9766c9d116ff
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-wg9q-ppqw-6q38
Applied-Upstream: 1.0.19

In the WPP slice decoder ctbAddrRS = ctbRow * ctbsWidth can exceed the
allocated vector size, causing out-of-bounds reads.

Gbp-Pq: Name CVE-2026-45383.patch

CVE-2026-45382: fix CTB OOB access when pps.sps mismatches active sps

Origin: upstream, https://github.com/strukturag/libde265/commit/c33b4f63ae9056b00f34a31874fed55cd0aa29c9
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-hwhx-x2mq-ccr9
Applied-Upstream: 1.0.19

Malformed PPS data creates an out-of-bounds index into the CtbAddrRStoTS
array, causing a heap-buffer-overflow read in decode_slice_unit_tiles.

Gbp-Pq: Name CVE-2026-45382.patch

CVE-2024-38949, CVE-2024-38950: fix SDL OOB in dec265 display path

Origin: upstream, https://github.com/strukturag/libde265/commit/4089de0845e0009e019be4ca5cbebaf2aee0a8ce
Bug: https://github.com/strukturag/libde265/issues/460
Bug-Debian: https://bugs.debian.org/1074416
Applied-Upstream: 1.0.19

Heap buffer overflow in the dec265 SDL output on 4:4:4 streams
(display444as420) and on mid-stream resolution changes.

Gbp-Pq: Name CVE-2024-38949_CVE-2024-38950.patch

CVE-2025-61147: check for valid integer command line parameters

Origin: upstream, https://github.com/strukturag/libde265/commit/8b17e0930f77db07f55e0b89399a8f054ddbecf7
Bug: https://github.com/strukturag/libde265/issues/484
Bug-Debian: https://bugs.debian.org/1129257
Applied-Upstream: 1.0.18

Invalid numeric arguments (e.g. for --framedrop) made dec265 crash with a
segmentation fault in decoder_context::compute_framedrop_table().

Gbp-Pq: Name CVE-2025-61147.patch

[PATCH] Fix missing "LIBS_PRIVATE" for libde265.pc in autoconf builds.

From 56d1cf52e43d734692721c99b72815c0fee1f184 Mon Sep 17 00:00:00 2001
Forwarded: https://github.com/strukturag/libde265/pull/439

Forwarded: https://github.com/strukturag/libde265/pull/439
Gbp-Pq: Name fix-private-libs-pc.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.

Gbp-Pq: Name recycle_sps_if_possible.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

Gbp-Pq: Name use_sps_from_the_image.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)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.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.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.15-1+deb13u1) trixie-security; urgency=medium

  * Non-maintainer upload by the Security Team.
  * Backport upstream security fixes
    CVE-2024-38949, CVE-2024-38950, CVE-2025-61147, CVE-2026-45382,
    CVE-2026-45383, CVE-2026-49295, CVE-2026-49337, CVE-2026-49346,
    CVE-2026-54240, CVE-2026-54241

[dgit import unpatched libde265 1.0.15-1+deb13u1]

Import libde265_1.0.15-1+deb13u1.debian.tar.xz

[dgit import tarball libde265 1.0.15-1+deb13u1 libde265_1.0.15-1+deb13u1.debian.tar.xz]

Merge version 1.0.13-1+rpi1 and 1.0.15-1 to produce 1.0.15-1+rpi1

Import libde265_1.0.15.orig.tar.gz

[dgit import orig libde265_1.0.15.orig.tar.gz]

Merge libde265 (1.0.15-1) import into refs/heads/workingbranch

[PATCH] Fix missing "LIBS_PRIVATE" for libde265.pc in autoconf builds.

From 56d1cf52e43d734692721c99b72815c0fee1f184 Mon Sep 17 00:00:00 2001
Forwarded: https://github.com/strukturag/libde265/pull/439

Forwarded: https://github.com/strukturag/libde265/pull/439
Gbp-Pq: Name fix-private-libs-pc.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.

Gbp-Pq: Name recycle_sps_if_possible.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

Gbp-Pq: Name use_sps_from_the_image.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)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.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.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.15-1) unstable; urgency=medium

  * New upstream version 1.0.15
  * Fixes CVE-2023-49465, CVE-2023-49467, CVE-2023-49468.
  * Add patch to fix "Libs.private" in libde265.pc.

[dgit import unpatched libde265 1.0.15-1]

Import libde265_1.0.15-1.debian.tar.xz

[dgit import tarball libde265 1.0.15-1 libde265_1.0.15-1.debian.tar.xz]

Merge version 1.0.11-1+rpi1 and 1.0.13-1 to produce 1.0.13-1+rpi1

Merge libde265 (1.0.13-1) import into refs/heads/workingbranch

[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.

Gbp-Pq: Name recycle_sps_if_possible.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

Gbp-Pq: Name use_sps_from_the_image.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)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.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.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.13-1) unstable; urgency=medium

  * New upstream version 1.0.13
  * Fixes CVE-2023-47471 (Closes: #1056187), CVE-2023-43887.
  * Update patches for new upstream version.
  * d/control: Upstream switched examples to SDL2 (Closes: #1038097).
  * Update symbols for new upstream version.

[dgit import unpatched libde265 1.0.13-1]

Import libde265_1.0.13.orig.tar.gz

[dgit import orig libde265_1.0.13.orig.tar.gz]

Import libde265_1.0.13-1.debian.tar.xz

[dgit import tarball libde265 1.0.13-1 libde265_1.0.13-1.debian.tar.xz]

Merge libde265 (1.0.12-2) import into refs/heads/workingbranch

[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.

Gbp-Pq: Name recycle_sps_if_possible.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

Gbp-Pq: Name use_sps_from_the_image.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)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.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.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.12-2) unstable; urgency=medium

  * Team upload
  * Clean Makefiles (Closes: #1047354)

  [ Vladimir Petko ]
  * add libde265 decoder smoke test (Closes: #1052214)

[dgit import unpatched libde265 1.0.12-2]

Import libde265_1.0.12-2.debian.tar.xz

[dgit import tarball libde265 1.0.12-2 libde265_1.0.12-2.debian.tar.xz]

Merge libde265 (1.0.12-1) import into refs/heads/workingbranch

Import libde265_1.0.12.orig.tar.gz

[dgit import orig libde265_1.0.12.orig.tar.gz]

[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.

Gbp-Pq: Name recycle_sps_if_possible.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

Gbp-Pq: Name use_sps_from_the_image.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)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.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.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.12-1) unstable; urgency=medium

  * New upstream version 1.0.12
  * Fixes CVE-2023-27102, CVE-2023-27103

[dgit import unpatched libde265 1.0.12-1]

Import libde265_1.0.12-1.debian.tar.xz

[dgit import tarball libde265 1.0.12-1 libde265_1.0.12-1.debian.tar.xz]

Merge version 1.0.9-1.1+rpi1 and 1.0.11-1 to produce 1.0.11-1+rpi1

Merge libde265 (1.0.11-1) import into refs/heads/workingbranch

[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.

Gbp-Pq: Name recycle_sps_if_possible.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

Gbp-Pq: Name use_sps_from_the_image.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)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.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.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.11-1) unstable; urgency=medium

  [ Tobias Frost ]
  * Make my patch less noisy.

  [ Joachim Bauch ]
  * New upstream version 1.0.11
  * Unpackaged upstream version 1.0.10 fixes the following CVEs, most caused
    by the same underlying issue:
    CVE-2020-21594, CVE-2020-21595, CVE-2020-21596, CVE-2020-21597,
    CVE-2020-21598, CVE-2020-21599, CVE-2020-21600, CVE-2020-21601,
    CVE-2020-21602, CVE-2020-21603, CVE-2020-21604, CVE-2020-21605,
    CVE-2020-21606, CVE-2022-1253, CVE-2022-43236, CVE-2022-43237,
    CVE-2022-43238, CVE-2022-43239, CVE-2022-43240, CVE-2022-43241,
    CVE-2022-43242, CVE-2022-43243, CVE-2022-43244, CVE-2022-43245,
    CVE-2022-43248, CVE-2022-43249, CVE-2022-43250, CVE-2022-43252,
    CVE-2022-43253, CVE-2022-47655
  * Remove patch applied upstream.
  * Update patches for new upstream version.
  * Remove copyright entry for file no longer present in upstream.
  * Update symbols for new upstream version.
  * Bump "Standards-Version" to 4.6.2

[dgit import unpatched libde265 1.0.11-1]

Import libde265_1.0.11.orig.tar.gz

[dgit import orig libde265_1.0.11.orig.tar.gz]

Import libde265_1.0.11-1.debian.tar.xz

[dgit import tarball libde265 1.0.11-1 libde265_1.0.11-1.debian.tar.xz]

Merge version 1.0.9-1+rpi1 and 1.0.9-1.1 to produce 1.0.9-1.1+rpi1

Merge libde265 (1.0.9-1.1) import into refs/heads/workingbranch

[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.

Gbp-Pq: Name recycle_sps_if_possible.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

Gbp-Pq: Name use_sps_from_the_image.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)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Add visibility.m4 from upstream which is missing in the

Forwarded: https://github.com/strukturag/libde265/pull/355

release tarball.
===================================================================

Gbp-Pq: Name m4-visibility.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.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.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.9-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Apply patches to mitigate asan failures:
    reject_reference_pics_from_different_sps.patch and
    use_sps_from_the_image.patch.
  * Combined, this two patches fixes:
    - CVE-2022-43243, CVE-2022-43248, CVE-2022-43253 (Closes: #1025816)
    - CVE-2022-43235, CVE-2022-43236, CVE-2022-43237, CVE-2022-43238,
      CVE-2022-43239, CVE-2022-43240, CVE-2022-43241, CVE-2022-43242,
      CVE-2022-43244, CVE-2022-43250, CVE-2022-43252 (Closes: #1027179)
    - CVE-2022-47655
  * Additional patch recycle_sps_if_possible.patch to avoid over-rejecting
    valid video streams due to reject_reference_pics_from_different_sps.patch.
  * Modifying past changelog entries to indicate when vulnerabilities were
    fixed:
    - In 1.0.9-1, in total 11 CVE's. see #1004963 and #1014999
    - In 1.0.3-1, 1 CVE, see #1029396
  * drop unused Build-Depends: libjpeg-dev, libpng-dev and libxv-dev
    (Closes: #981260)

[dgit import unpatched libde265 1.0.9-1.1]

Import libde265_1.0.9-1.1.debian.tar.xz

[dgit import tarball libde265 1.0.9-1.1 libde265_1.0.9-1.1.debian.tar.xz]

Merge version 1.0.8-1+rpi1 and 1.0.9-1 to produce 1.0.9-1+rpi1

Merge libde265 (1.0.9-1) import into refs/heads/workingbranch

Import libde265_1.0.9.orig.tar.gz

[dgit import orig libde265_1.0.9.orig.tar.gz]

Add visibility.m4 from upstream which is missing in the

Forwarded: https://github.com/strukturag/libde265/pull/355

release tarball.
===================================================================

Gbp-Pq: Name m4-visibility.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch