v2.0.0 macOS/arm64: SIGSEGV parsing a CLIPINF entry with a large EP map (repro attached)

[alksdjkjdf]

Hello! I have a blu-ray that worked[1] in 1.8.3, but seg faulted in 2.0.0. I tried to repro

[1] note that even in 1.8.3 the blu-ray had some odd stuff going on. still, a segfault is a segfault

Summary

MakeMKV v2.0.0 darwin(arm64-release) crashes with a null-pointer dereference while opening a Blu-ray (or an ISO of one) in direct disc access mode. v1.18.3 opens the same disc successfully on the same machine and the same drive.

I bisected it down to a single BDMV/CLIPINF/*.clpi file whose CPI (EP map) section is unusually large. No playlist referencing the clip is required - merely having the .clpi and a same-named STREAM/*.m2ts present on the volume is enough to crash it.

A reproducer is attached. It contains no video content.


Environment

Code: Select all

Version         MakeMKV v2.0.0 darwin(arm64-release)   <- crashes
Working version MakeMKV v1.18.3 darwin(arm64-release)  <- opens the same disc fine
OS              macOS 26.6, Apple Silicon (arm64)
Drive           BD-RE PIONEER BD-RW BDR-UD04 1.14
Disc            Japanese BD, unencrypted (no /AACS directory),
                playlist/segment obfuscated

Minimal reproducer

Attached: makemkv-2.0.0-crash-repro.zip. The stream file is 2048 zero bytes, and there is no copyrighted content in it.

Code: Select all

BDMV/index.bdmv            120 bytes   (required - omitting it avoids the crash)
BDMV/MovieObject.bdmv      458 bytes   (required - omitting it avoids the crash)
BDMV/CLIPINF/31643.clpi  29330 bytes   <-- the trigger
BDMV/STREAM/31643.m2ts    2048 bytes   (zeros; any size >= 192 works,
                                        contents are irrelevant)

To reproduce:

Code: Select all

/Applications/MakeMKV.app/Contents/MacOS/makemkvcon -r info iso:makemkv-2.0.0-crash-repro.iso

Output stops immediately after the AACS probe and the process dies:

Code: Select all

MSG:1005 MakeMKV v2.0.0 darwin(arm64-release) started
MSG:3007 Using direct disc access mode
MSG:3305 AACS directory not present, assuming unencrypted disc
<SIGSEGV>

Code: Select all

echo $?

returns 139.

The raw four files are also included under repro-files/ in the zip, if you would rather build the image yourself:

Code: Select all

hdiutil makehybrid -udf -udf-volume-name TESTBD -o out.iso repro-files/

Crash

Code: Select all

exception : EXC_BAD_ACCESS / SIGSEGV
subtype   : KERN_INVALID_ADDRESS at 0x0000000000000000
stack     : makemkvcon 0x68b70 <- 0xd12c4 <- 0xca988 <- 0xc7be4 <- 0xc5a28 <- 0x61ff0

The stack is byte-identical between the physical disc and the synthetic ISO, so the attached reproducer exercises the same code path. Offsets are imageOffset into makemkvcon; crash-excerpt.txt in the zip has both in full. I can supply a full core dump on request.


Bisection evidence

Starting from a synthetic UDF image of the whole disc's metadata (1262 CLIPINF + 23 PLAYLIST + stub streams, 320 MB), which crashes identically to the real disc:

Code: Select all

Playlist 00089.mpls truncated to 113 playitems .................. ok
Same, 114 playitems (adds clip 31643) ........................... CRASH
113 playitems, 31643.clpi + .m2ts present but UNREFERENCED ...... CRASH
114 playitems, but 31643.clpi contents swapped for a small clip's  ok
No playlists at all, only 31643.clpi + 31643.m2ts ............... CRASH
31643.clpi present, no 31643.m2ts ............................... ok
Stream file of zeros / random bytes / synthetic TS header ....... CRASH (all three)
index.bdmv omitted .............................................. ok
MovieObject.bdmv omitted ........................................ ok

So the necessary and sufficient set is: index.bdmv + MovieObject.bdmv + 31643.clpi + any non-empty 31643.m2ts.


What is unusual about that CLPI

31643 is a 1:01:35 clip, so its EP map is far larger than the disc's other clips, which run 23-120 seconds:

Code: Select all

31643.clpi  size=29330  SequenceInfo@220 ProgramInfo@260 CPI@322 ClipMark@29326
            CPI (EP map) section length = 29000 bytes
15040.clpi  size=  924  CPI section length =   608 bytes
06713.clpi  size=  540  CPI section length =   224 bytes

Note the crash also occurs with a 2048-byte stream file, whose SPNs cannot possibly cover the EP map's entries - which suggests the EP map is walked without validating entries against the actual stream extent. But it also crashes on the real disc where that stream is 16.8 GB, so a size mismatch alone is not the whole story.


Why 1.18.3 survives

v1.18.3 logs only:

Code: Select all

Optical drive "..." opened in OS access mode.

v2.0.0 adds:

Code: Select all

Using LibreDrive mode (v02.1 id=<redacted>)
Using direct disc access mode

v1.18.3 reads through macOS's UDF driver; v2.0.0 parses the volume itself. This particular disc is structurally hostile - 1262 .m2ts files presenting 452.6 GB of apparent data on a 41.4 GB volume via overlapping UDF extents (every clip exists as exactly 11 aliases), and 00003.mpls is 126 bytes while its own header points the PlayListMark table to offset 11378.

That said, the minimal reproducer above involves none of that. A plain, well-formed UDF image containing one CLIPINF entry is enough.


Workarounds attempted

• file:<folder> is not a workaround - MakeMKV detects the folder is the optical drive's root, reports that it will open the disc instead, and crashes the same way (exit 139).
• Debug logging could not be captured: --debug, --debug=<file>, and app_ShowDebug = "1" in settings.conf all produced no log file, because the crash happens before any flush. Happy to try a different incantation if there is one.