OESA-2025-2272

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler. ufshcderrhandlingprepare() calls ufshcdrpmgetsync(). The latter function can only succeed if UFSHCDEHINPROGRESS is not set because resuming involves submitting a SCSI command and ufshcdqueuecommand() returns SCSIMLQUEUEHOSTBUSY if UFSHCDEHINPROGRESS is set. Fix this hang by setting UFSHCDEHINPROGRESS after ufshcdrpmgetsync() has been called instead of before.(CVE-2025-38119)

A NULL pointer dereference vulnerability exists in the Linux kernel's target subsystem. The function corescsi3decodespeciport() unconditionally calls corescsi3lunaclundependitem() passing a potentially NULL destse_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)

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

bpf: Fix oob access in cgroup local storage

Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpfcgrunctx holds an bpfprogarrayitem which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpfgetlocal_storage() pick this up from the runtime context:

ctx = containerof(current->bpfctx, struct bpfcgrunctx, runctx); storage = ctx->progitem->cgroupstorage[stype];

if (stype == BPFCGROUPSTORAGESHARED) ptr = &READONCE(storage->buf)->data[0]; else ptr = thiscpuptr(storage->percpu_buf);

For the second program which was called from the originally attached one, this means bpfgetlocal_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access.

To fix this issue, we need to extend bpfmapowner with an array of storagecookie[] to match on i) the exact maps from the original program if the second program was using bpfgetlocalstorage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.(CVE-2025-38502)

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

net/mlx5: Check device memory pointer before usage

Add a NULL check before accessing device memory to prevent a crash if dev->dm allocation in mlx5initonce() fails.(CVE-2025-38645)

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

ftrace: Also allocate and copy hash for reading of filter files

Currently the reader of setftracefilter and setftracenotrace just adds the pointer to the global tracer hash to its iterator. Unlike the writer that allocates a copy of the hash, the reader keeps the pointer to the filter hashes. This is problematic because this pointer is static across function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs.

Allocate and copy the hash for reading the filter files like it is done for the writers. This not only fixes UAF bugs, but also makes the code a bit simpler as it doesn't have to differentiate when to free the iterator's hash between writers and readers.(CVE-2025-39689)