BDU:2026-06912

ROS-20260528-80-0001

Уязвимость kernel-lt

ROS-20260528-73-0001

Уязвимость kernel-lt

ALT-PU-2026-7835

ALT-PU-2026-7835: package `kernel-image-std-def` update to version 5.10.256-alt1

ALT-PU-2026-7833

ALT-PU-2026-7833: package `kernel-image-un-def` update to version 6.1.173-alt1

CVE-2026-46333

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