CVE-2026-46333

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptrace: slightly saner &amp;#39;get_dumpable()&amp;#39; logic<br /> <br /> The &amp;#39;dumpability&amp;#39; of a task is fundamentally about the memory image of<br /> the task - the concept comes from whether it can core dump or not - and<br /> makes no sense when you don&amp;#39;t have an associated mm.<br /> <br /> And almost all users do in fact use it only for the case where the task<br /> has a mm pointer.<br /> <br /> But we have one odd special case: ptrace_may_access() uses &amp;#39;dumpable&amp;#39; to<br /> check various other things entirely independently of the MM (typically<br /> explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for<br /> threads that no longer have a VM (and maybe never did, like most kernel<br /> threads).<br /> <br /> It&amp;#39;s not what this flag was designed for, but it is what it is.<br /> <br /> The ptrace code does check that the uid/gid matches, so you do have to<br /> be uid-0 to see kernel thread details, but this means that the<br /> traditional "drop capabilities" model doesn&amp;#39;t make any difference for<br /> this all.<br /> <br /> Make it all make a *bit* more sense by saying that if you don&amp;#39;t have a<br /> MM pointer, we&amp;#39;ll use a cached "last dumpability" flag if the thread<br /> ever had a MM (it will be zero for kernel threads since it is never<br /> set), and require a proper CAP_SYS_PTRACE capability to override.