Re: [PATCH 1/2] libselinux: prevent ReDoS in file context regex matching

On Fri, Aug 21, 2026 at 8:55 AM Stephen Smalley
<[email protected]> wrote:
>
> On Wed, Jul 29, 2026 at 9:40 AM Petr Matyas <[email protected]> wrote:
> >
> > The PCRE2 interpreter is susceptible to catastrophic backtracking on
> > crafted file context patterns or lookup keys. Since libselinux never
> > called pcre2_jit_compile(3) or pcre2_jit_match(3), the JIT was
> > available but unused, leaving the interpreter exposed on all platforms.
> >
> > Fix with two complementary mitigations:
> >
> > 1. Call pcre2_jit_compile() after every pattern compilation (including
> >    mmap deserialization) to engage JIT for both complete and partial
> >    matching. regex_match() now calls pcre2_jit_match() and falls back to
> >    pcre2_match() only on PCRE2_ERROR_JIT_BADOPTION (JIT unavailable or
> >    not compiled for the requested mode).
> >
> > 2. Create a shared pcre2_match_context with a backtrack step limit of
> >    10 000 000 and pass it to both pcre2_jit_match() and the fallback
> >    pcre2_match(). PCRE2_ERROR_MATCHLIMIT is treated as no-match to keep
> >    the lookup safe rather than failing noisily. This bounds worst-case
> >    matching time to milliseconds for any pattern/subject combination,
> >    regardless of JIT availability.
> >
> > The vulnerability was reproduced and confirmed fixed on:
> > - RHIVOS 2.0 / aarch64
> > - RHEL 10.3 / x86_64
> > - Fedora 44 / x86_64
> >
> > Reproducer (149 bytes, base64):
> > AwovMi0GLy8GCygKeAYGKwYLKAoKCgAAAPpXKgsoCi8vBgs8PG5vbmU+PgovMi0GLy8GCygKeAYG
> > KwYLKAoKCiNXLy8wCwsoCgojV1dXClcqCygKLy8vV1cueHhXV1d4eHgveCsGCygKCgonVy9XV3cy
> > eHgveAcGJAsoCi8tLwYvMi0GLy8GCzw8bm9uZT4+3q2+7y8=
> >
> > Signed-off-by: Petr Matyas <[email protected]>
>
> It occurs to me belatedly that this change (which we already merged
> along with several follow-ups)
> likely triggers SELinux execmem checks on any process that uses
> selabel_open(SELABEL_CTX_FILE,...)
> due to the JIT compilation.

I experimentally confirmed that this does trigger execmem denials on
Fedora if I setsebool deny_execmem=True. The denial is not fatal since
it falls back to the interpreter but it will show up in the audit logs
for any confined domain or if deny_execmem=True for all domains.

> Given that fact along with the fact that
> we are still seeing cases [1] where
> oss-fuzz can trigger stack smashing on pathological regexes and that
> this was originally motivated by
> concerns about such regexes and that the source of these regexes is
> always trusted (root-only config,
> and in the case of Android integrity-verified, I am starting to wonder
> if this change is harmful rather than
> beneficial. Open to others' thoughts. At the very least, I suspect
> Android might want to disable this.
>
> [1] https://lore.kernel.org/selinux/CAEjxPJ6-b4KmkgSgO7hXf+8ZGgRtR_JkS1ZQU-ULVk0aex5zCw@mail.gmail.com/T/#t