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

On Fri, Aug 21, 2026 at 9:21 AM Stephen Smalley
<[email protected]> wrote:
>
> 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.

Barring objections or counter-proposals, I think we may want to revert
the use of the PCRE2 JIT
to avoid users of libselinux selabel_open(SELABEL_CTX_FILE, ...)
suddenly triggering execmem denials.
We can keep the other part of this change intact.

> >
> > [1] https://lore.kernel.org/selinux/CAEjxPJ6-b4KmkgSgO7hXf+8ZGgRtR_JkS1ZQU-ULVk0aex5zCw@mail.gmail.com/T/#t