OESA-2025-2535

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

blk-mq: fix NULL dereference on q->elevator in blkmqelvswitchnone

After grabbing q->sysfs_lock, q->elevator may become NULL because of elevator switch.

Fix the NULL dereference on q->elevator by checking it with lock.(CVE-2023-53292)

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

scsi: libiscsi: Initialize iscsiconn->dddata only if memory is allocated

In case of an ibfastregmr allocation failure during iSER setup, the machine hits a panic because iscsiconn->dddata is initialized unconditionally, even when no memory is allocated (ddsize == 0). This leads invalid pointer dereference during connection teardown.

Fix by setting iscsiconn->dddata only if memory is actually allocated.

Panic trace:

iser: isercreatefastregdesc: Failed to allocate ibfastregmr err=-12 iser: iserallocrxdescriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swakeuplocked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsiiserconnstop+0x88/0xb0 [ibiser] iscsistopconn+0x66/0xc0 [scsitransportiscsi] iscsiifstopconn+0x14a/0x150 [scsitransportiscsi] iscsiifrx+0x1135/0x1834 [scsitransportiscsi] ? netlinklookup+0x12f/0x1b0 ? netlinkdelivertap+0x2c/0x200 netlinkunicast+0x1ab/0x280 netlinksendmsg+0x257/0x4f0 ? _copyfromuser+0x29/0x60 socksendmsg+0x5f/0x70(CVE-2025-38700)

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

loop: Avoid updating block size under exclusive owner

Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in _getblkslow() due to requested buffer size not matching block device block size.

Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.(CVE-2025-38709)

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

NFS: Fix a race when updating an existing write

After nfslockandjoinrequests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfsinoderemoverequest() from succeeding until we actually lock the page group. The reason is that whoever called nfsinoderemoverequest() doesn't necessarily have a lock on the page group head.

So in order to avoid races, let's take the page group lock earlier in nfslockandjoinrequests(), and hold it across the removal of the request in nfsinoderemove_request().(CVE-2025-39697)

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

block: avoid possible overflow for chunksectors check in blkstack_limits()

In blkstacklimits(), we check that the t->chunksectors value is a multiple of the t->physicalblock_size value.

However, by finding the chunksectors value in bytes, we may overflow the unsigned int which holds chunksectors, so change the check to be based on sectors.(CVE-2025-39795)