configure.ac | 4 1 + 3 - 0 !
libde265/configparam.h | 24 12 + 12 - 0 !
libde265/encoder/Makefile.am | 12 12 + 0 - 0 !
libde265/encoder/algo/Makefile.am | 8 8 + 0 - 0 !
libde265/image-io.cc | 6 3 + 3 - 0 !
libde265/image-io.h | 50 25 + 25 - 0 !
libde265/quality.h | 6 3 + 3 - 0 !
7 files changed, 64 insertions(+), 46 deletions(-)

 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.

Makefile.am | 7 0 + 7 - 0 !
dec265/Makefile.am | 8 1 + 7 - 0 !
2 files changed, 1 insertion(+), 14 deletions(-)

 disable building of some internal tools that no longer link
 because internal symbols are no longer exported.

libde265/motion.cc | 10 10 + 0 - 0 !
1 file changed, 10 insertions(+)

 [patch] try to mitigate asan failures.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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)

libde265/motion.cc | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [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

libde265/decctx.cc | 273 273 + 0 - 0 !
libde265/sps.cc | 6 6 + 0 - 0 !
2 files changed, 279 insertions(+)

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

libde265/decctx.cc | 5 3 + 2 - 0 !
1 file changed, 3 insertions(+), 2 deletions(-)

---

libde265/de265.cc | 2 2 + 0 - 0 !
libde265/de265.h | 3 2 + 1 - 0 !
libde265/motion.cc | 10 10 + 0 - 0 !
3 files changed, 14 insertions(+), 1 deletion(-)

---

libde265/decctx.cc | 9 5 + 4 - 0 !
1 file changed, 5 insertions(+), 4 deletions(-)

---

libde265/slice.cc | 11 10 + 1 - 0 !
1 file changed, 10 insertions(+), 1 deletion(-)

---

libde265/motion.cc | 9 8 + 1 - 0 !
1 file changed, 8 insertions(+), 1 deletion(-)

---

libde265/slice.cc | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

---

libde265/image.h | 9 8 + 1 - 0 !
1 file changed, 8 insertions(+), 1 deletion(-)

---