Re: [PATCH] scripts/oss-fuzz: build PCRE2 from source with sanitizer instrumentation

On Thu, Aug 6, 2026 at 8:27 AM Stephen Smalley
<[email protected]> wrote:
>
> On Wed, Aug 5, 2026 at 12:17 PM Stephen Smalley
> <[email protected]> wrote:
> >
> > On Wed, Aug 5, 2026 at 9:29 AM Stephen Smalley
> > <[email protected]> wrote:
> > >
> > > On Wed, Aug 5, 2026 at 6:18 AM Petr Matyas <[email protected]> wrote:
> > > >
> > > > The selabel_file fuzzers link against the system libpcre2, which is not
> > > > instrumented when building with -fsanitize=memory.  MSan requires all
> > > > libraries to be instrumented; uninstrumented libraries can produce false
> > > > positives because their writes do not update the sanitizer's shadow memory.
> > > >
> > > > In practice this causes a spurious use-of-uninitialized-value report:
> > > > pcre2_compile() writes literal character bytes via direct assignment (not
> > > > through memset/memcpy), so MSan's shadow memory does not reflect those
> > > > writes.  pcre2_jit_compile() then calls memcmp() in detect_repeat() over
> > > > compiled bytecode containing those character bytes, and MSan flags the
> > > > comparison as reading uninitialized memory.
> > > >
> > > > The PCRE2 maintainers confirmed this is a false positive per MSan
> > > > documentation and declined to change the library [1].
> > > >
> > > > Fix by building PCRE2 from source with the same -fsanitize= flags as the
> > > > rest of the fuzzer build.  With instrumentation, all pcre2_compile()
> > > > writes are tracked, detect_repeat()'s memcmp() sees properly initialized
> > > > bytes, and the false positive disappears.  Both selabel_file fuzzers are
> > > > now linked against the resulting static libpcre2-8.a from DESTDIR instead
> > > > of the system shared library.
> > > >
> > > > [1] https://github.com/KwisatzHaderach/pcre2/pull/1
> > > >
> > > > Signed-off-by: Petr Matyas <[email protected]>
> > >
> > > Acked-by: Stephen Smalley <[email protected]>
> >
> > Merged.
>
> This resolved the issue with oss-fuzz. Thank you for investigating and
> fixing it!

Got a new oss-fuzz report that doesn't reproduce if I revert your
earlier prevent ReDOS patch,
so it seems to be tied to the use of the pcre2 JIT even though the
stack trace isn't helpful.
Output below and reproducer attached.

 +----------------------------------------Release Build
Stacktrace----------------------------------------+
Command: /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds-honggfuzz_selinux_32ddf78d9f476617df7a8f4cf22b4d9340aef874/revisions/selabel_file_compiled-fuzzer
Time ran: 0.02901911735534668
Accepting input from '[STDIN]'
Usage for fuzzing: honggfuzz -P [flags] --
/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds-honggfuzz_selinux_32ddf78d9f476617df7a8f4cf22b4d9340aef874/revisions/selabel_file_compiled-fuzzer
AddressSanitizer:DEADLYSIGNAL
=================================================================
==250==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x79a295c29113 bp 0x75a2940e2e20 sp 0x7ffe28467260 T0)
==250==The signal is caused by a READ memory access.
==250==Hint: address points to the zero page.
    #0 0x79a295c29113  (<unknown module>)
==250==Register values:
rax = 0x000075c2951e002f  rbx = 0x000075c2951e0031  rcx =
0x000075c2951e002f  rdx = 0x0000000000000000
rdi = 0x000075c2951e002f  rsi = 0x0000000000000001  rbp =
0x000075a2940e2e20  rsp = 0x00007ffe28467260
 r8 = 0x000079a295c290b2   r9 = 0x00007fffffffff01  r10 =
0x00007fffffffff01  r11 = 0x00000eced2a34001
r12 = 0x000075a2940e2e20  r13 = 0x0000000000989680  r14 =
0x000075a2948d0020  r15 = 0x000075a2948d8020
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (<unknown module>)
==250==ABORTING
Original Stacktrace on revision
64c49eb31cdfa4336b1c71e09b13b8b08435cc59 (26 lines)
[Environment] ASAN_OPTIONS=exitcode=77
+----------------------------------------Release Build
Stacktrace----------------------------------------+
Command: /mnt/scratch0/clusterfuzz/resources/platform/linux/unshare -c
-n /mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_selinux_32ddf78d9f476617df7a8f4cf22b4d9340aef874/revisions/selabel_file_compiled-fuzzer
-runs=100 '/mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/cec16e5ee8803994da27df80ea97364cE.-6.ADDR.0.INSTR.[UNKNOWN].fuzz'
Time ran: 0.040236473083496094
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 3046068775
INFO: Loaded 1 modules   (32680 inline 8-bit counters): 32680
[0x5ae1f2ea5fe0, 0x5ae1f2eadf88),
INFO: Loaded 1 PC tables (32680 PCs): 32680 [0x5ae1f2eadf88,0x5ae1f2f2da08),
/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_selinux_32ddf78d9f476617df7a8f4cf22b4d9340aef874/revisions/selabel_file_compiled-fuzzer:
Running 1 inputs 100 time(s) each.
Running: /mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/cec16e5ee8803994da27df80ea97364cE.-6.ADDR.0.INSTR.[UNKNOWN].fuzz
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1036==ERROR: AddressSanitizer: SEGV on unknown address
0x000000000000 (pc 0x7e85a7a65680 bp 0x7a85a5cf1220 sp 0x7ffcef4417a0
T0)
==1036==The signal is caused by a READ memory access.
==1036==Hint: address points to the zero page.
    #0 0x7e85a7a65680  (<unknown module>)
==1036==Register values:
rax = 0x0000000000000000  rbx = 0x00007aa5a6de0091  rcx =
0x0000000000000000  rdx = 0x00007e85a7a66108
rdi = 0x00007aa5a6de008f  rsi = 0x0000000000000001  rbp =
0x00007a85a5cf1220  rsp = 0x00007ffcef4417a0
 r8 = 0x00007e85a7a65456   r9 = 0x00005ae1f2e4f7e0  r10 =
0x00007fffffffff01  r11 = 0x00000f6b34db4001
r12 = 0x00007a85a5cf1220  r13 = 0x000000000098967d  r14 =
0x00007a85a64d0020  r15 = 0x00007a85a64d7fe0
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (<unknown module>)
==1036==ABORTING