CVE-2026-46333

Beschrijving NL

In de Linux kernel is de volgende kwetsbaarheid verholpen:

ptrace: iets gezondere 'get_dumpable()' logica

De 'dumpability' van een taak gaat fundamenteel over het geheugenbeeld van
de taak - het concept komt voort uit het feit of het kern kan dumpen of niet - en
heeft geen zin als je geen bijbehorende mm hebt. En bijna alle gebruikers gebruiken het in feite alleen voor het geval dat de taak
heeft een mm aanwijzer. Maar we hebben een vreemd speciaal geval: ptrace_may_access() gebruikt 'dumpable' om
controleer verschillende andere dingen volledig onafhankelijk van de MM (typisch
expliciet gebruik van vlaggen zoals PTRACE_mode_READ_FSCREDS). Inclusief voor
threads die geen VM meer hebben (en misschien ook nooit hebben gehad, zoals de meeste kernels)
draden). Het is niet waar deze vlag voor is ontworpen, maar het is wat het is. De ptrace-code controleert wel of de uid/gid overeenkomt, dus je moet
uid-0 om de details van de kerneldraad te zien, maar dit betekent dat de
traditioneel "drop capabilities" -model maakt geen verschil voor
dit alles. Maak het allemaal een *beetje* logischer door te zeggen dat als je geen
MM-aanwijzer, we gebruiken een vlag voor "laatste dumpbaarheid" in de cache als de thread
ooit een MM gehad (het zal nul zijn voor kernel threads omdat het nooit
ingesteld), en vereisen een juiste CAP_sys_PTRACE-mogelijkheid om te overschrijven.

Origineel (Engels) tonen

In the Linux kernel, the following vulnerability has been resolved:

ptrace: slightly saner 'get_dumpable()' logic

The 'dumpability' of a task is fundamentally about the memory image of
the task - the concept comes from whether it can core dump or not - and
makes no sense when you don't have an associated mm.

And almost all users do in fact use it only for the case where the task
has a mm pointer.

But we have one odd special case: ptrace_may_access() uses 'dumpable' to
check various other things entirely independently of the MM (typically
explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for
threads that no longer have a VM (and maybe never did, like most kernel
threads).

It's not what this flag was designed for, but it is what it is.

The ptrace code does check that the uid/gid matches, so you do have to
be uid-0 to see kernel thread details, but this means that the
traditional "drop capabilities" model doesn't make any difference for
this all.

Make it all make a *bit* more sense by saying that if you don't have a
MM pointer, we'll use a cached "last dumpability" flag if the thread
ever had a MM (it will be zero for kernel threads since it is never
set), and require a proper CAP_SYS_PTRACE capability to override.

Beschrijving NL

Vendors

Affected products

References