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

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. 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