Recent changes to patches

#62 Potential Overflow at `pnm2y4m.c`

Changgong Lee — Mon, 30 Sep 2024 03:57:05 -0000

This error was discovered by a static analyzer, and trace was manually reviewed.
I apologize that I can't provide a triggering testcase for this.

#60 Missing library when linking

Steven Schultz — Sat, 03 Aug 2024 02:17:44 -0000

status: open --> wont-fix
assigned_to: Steven Schultz
Group: -->

#63 gcc-15 build fix

Steven Schultz — Mon, 22 Jul 2024 02:02:22 -0000

status: open --> closed-fixed
assigned_to: Steven Schultz
Group: -->

gcc-15 build fix

Sergei Trofimovich — Sun, 21 Jul 2024 22:03:25 -0000

Without the change build of mjpegtools on upcoming gcc-15 will fail as:

In file included from SetRegion2D.hh:12,
                 from MotionSearcher.hh:15,
                 from newdenoise.cc:19:
Region2D.hh: In member function 'void Region2D<INDEX, SIZE>::UnionDebug(Status_t&, INDEX, INDEX, INDEX, REGION_TEMP&)':
Region2D.hh:439:34: error: 'class Region2D<INDEX, SIZE>' has no member named 'DoesContainPoint'
  439 |                         || this->DoesContainPoint (rHere.m_tnY, tnX)))
      |                                  ^~~~~~~~~~~~~~~~
Region2D.hh:446:29: error: 'class Region2D<INDEX, SIZE>' has no member named 'Begin'
  446 |         for (itHere = this->Begin(); itHere != this->End(); ++itHere)
      |                             ^~~~~
Region2D.hh:446:54: error: 'class Region2D<INDEX, SIZE>' has no member named 'End'
  446 |         for (itHere = this->Begin(); itHere != this->End(); ++itHere)
      |                                                      ^~~
Region2D.hh: In member function 'void Region2D<INDEX, SIZE>::UnionDebug(Status_t&, REGION_O&, REGION_TEMP&)':
Region2D.hh:549:35: error: 'class Region2D<INDEX, SIZE>' has no member named 'DoesContainPoint'
  549 |                         && !this->DoesContainPoint (rHere.m_tnY, tnX))
      |                                   ^~~~~~~~~~~~~~~~
Region2D.hh:556:29: error: 'class Region2D<INDEX, SIZE>' has no member named 'Begin'
  556 |         for (itHere = this->Begin(); itHere != this->End(); ++itHere)
      |                             ^~~~~
Region2D.hh:556:54: error: 'class Region2D<INDEX, SIZE>' has no member named 'End'
  556 |         for (itHere = this->Begin(); itHere != this->End(); ++itHere)
      |                                                      ^~~
Region2D.hh: In member function 'void Region2D<INDEX, SIZE>::SubtractDebug(Status_t&, REGION_O&, REGION_TEMP&)':
Region2D.hh:635:37: error: 'class Region2D<INDEX, SIZE>' has no member named 'DoesContainPoint'
  635 |                         if (!(this->DoesContainPoint (rHere.m_tnY, tnX)
      |                                     ^~~~~~~~~~~~~~~~
Region2D.hh:643:29: error: 'class Region2D<INDEX, SIZE>' has no member named 'Begin'
  643 |         for (itHere = this->Begin(); itHere != this->End(); ++itHere)
      |                             ^~~~~
Region2D.hh:643:54: error: 'class Region2D<INDEX, SIZE>' has no member named 'End'
  643 |         for (itHere = this->Begin(); itHere != this->End(); ++itHere)
      |                                                      ^~~

As I understand the underlying issue is that Region2D::UnionDebug() and Region2D::SubtractDebug() can possibly be called without a resolution errors.

The error started appearing after gcc-15 expanded on more cases of problematic instantiations in https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=313afcfdabeab3e6705ac0bd1273627075be0023

Attaches patch fixes the build for me ongcc-15 from master branch.

gcc-15 build fix

Sergei Trofimovich — Sun, 21 Jul 2024 22:03:25 -0000

Ticket 63 has been modified: gcc-15 build fix
Edited By: Steven Schultz (sms00)
Status updated: 'open' => 'closed-fixed'
Owner updated: None => 'sms00'

#62 Potential Overflow at `pnm2y4m.c`

Bernhard Praschinger — Sun, 26 May 2024 08:10:39 -0000

That could be a problem. On a typically system the Int_Max it 4 byte, so width * height mus be larger than 4 bytes (2147483647) means that the resolution needs to be larger than 46340 (width) * 46340 (height) pixels. It's quite unlikely that this happens and I think that a lot of other tools in the encoding pipeline can handle images at that size.
Can you give a practical example how that overflow can be triggered ?

Potential Overflow at `pnm2y4m.c`

Changgong Lee — Wed, 08 May 2024 05:22:13 -0000

Dear authors,
There exists a potential integer overflow at the function read_bpm_raw in lavtools/pnm2y4m.c

603    int row_bytes = (width + 7) >> 3; 
604    int total_bytes = row_bytes * height; // potential integer overflow
605    uint8_t *pbm  = buffer + total_bytes - 1;
606    uint8_t *luma = buffer + (width * height) - 1; // potential integer overflow

it could potentially cause null pointer dereferences or other undefined behaviors by *(pbm--) and *(luma--) at 617 and 618 line
when row_bytes, or width * height overflow by arbitrary values assigned to width and height.

617    uint8_t bits = *(pbm--) >> shift;
618      while (shift < 8) {
619        *(luma--) = (bits & 0x1) ? Y_BLACK : Y_WHITE;
620        bits >>= 1;
621        shift++;
622        x--;
623      }

A possible fix suggestion would be adding additional if statements.
For example,

if ( width > INT_MAX / height || row_bytes > INT_MAX / height ) {
    mjpeg_error_exit1("invalid pnm width and height, %dx%d", width, height);
  }

#61 Potential Overflow

Changgong Lee — Tue, 07 May 2024 10:17:37 -0000

This was a mistake, I posted without filling in the contents.
I am terribly sorry. Could anyone please delete this ticket?

Potential Overflow

Changgong Lee — Tue, 07 May 2024 10:07:53 -0000

#60 Missing library when linking

Steven Schultz — Thu, 04 Feb 2021 15:04:42 -0000

Let us look and analyze the error message more closely:

/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libdv.so.4: error adding symbols

NOTE: 1) this is "ld" (the linker" running
2) "ld" explicitly mentions "libdv.so.4" and
3) "ld" has an error adding (finding) the symbol dv_decoder_new

So we have a linker that 1) does not scan a library (that it knows the name of) for a symbol and 2) insists that the library name be mentioned a 2nd time. That feels wrong.

From a SuSE 15.2 (and macOS behaves the same way) system the linking of lav2yuv looks like this ( I have spaced the info so it does not fold incorrectly or become truncated):

/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -pthread -Wall
-Wunused -o lav2yuv lav2yuv-lav2yuv.o lav2yuv-lav_common.o
../utils/libmjpegutils.la liblavfile.la liblavjpeg.la -lm
libtool: link: gcc -g -O2 -pthread -Wall -Wunused -o .libs/lav2yuv
lav2yuv-lav2yuv.o lav2yuv-lav_common.o ../utils/.libs/libmjpegutils.so
./.libs/liblavfile.so -L/usr/local/lib64 /usr/local/lib64/libquicktime.so
-lpthread -lz -ldl /usr/local/lib64/libdv.so
./.libs/liblavjpeg.so -ljpeg
/usr/local/src/mjpegtools/utils/.libs/libmjpegutils.so -lm -pthread

Look at the 3rd line from the bottom - you will see libdv.so

I believe that either libtool or ld is misconfigured on a system that needs a library to be added a 2nd time.

If it's been 7 years (and mjepgtools goes back MUCH further than that) since it became necessary to patch the build process for mjpegtools then that's when ld or libtool configuration was changed - best to fix the problem there.

At this time I can't see adding the patch when other systems sail thru without a problem.