OESA-2025-1113

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

pinmux: Use sequential access to access desc->pinmux data

When two client of the same gpio call pinctrlselectstate() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner.

Let's say two processes A, B executing in pinrequest() for the same pin and process A updates the desc->muxusecount but not yet updated the desc->muxowner while process B see the desc->muxusecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer.

Serialize the access to mux related setting with a mutex lock.

cpu0 (process A)            cpu1(process B)

pinctrlselectstate() { pinctrlselectstate() { pinrequest() { pinrequest() { ... .... } else { desc->muxusecount++; desc->muxusecount && strcmp(desc->mux_owner, owner)) {

     if (desc->mux_usecount > 1)
           return 0;
     desc->mux_owner = owner;

} }(CVE-2024-47141)

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

net/smc: check ipareaoffset and ipv6prefixes_cnt when receiving proposal msg

When receiving proposal msg in server, the field ipareaoffset and the field ipv6prefixescnt in proposal msg are from the remote client and can not be fully trusted. Especially the field ipareaoffset, once exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks ipareaoffset and ipv6prefixes_cnt before using them.(CVE-2024-49571)

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

spi: mpc52xx: Add cancelworksync before module remove

If we remove the module which will call mpc52xxspiremove it will free 'ms' through spiunregistercontroller. while the work ms->work will be used. The sequence of operations that may lead to a UAF bug.

Fix it by ensuring that the work is canceled before proceeding with the cleanup in mpc52xxspiremove.(CVE-2024-50051)

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

usb: typec: fix potential array underflow in ucsiccgsync_control()

The "command" variable can be controlled by the user via debugfs. The worry is that if conindex is zero then "&uc->ucsi->connector[conindex - 1]" would be an array underflow.(CVE-2024-53203)

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

zram: fix NULL pointer in compalgorithmshow()

LTP reported a NULL pointer dereference as followed:

CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _pistrcmp+0x24/0x140 lr : zcompavailableshow+0x60/0x100 [zram] sp : ffff800088b93b90 x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0 x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000 x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280 x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000 Call trace: _pistrcmp+0x24/0x140 compalgorithmshow+0x40/0x70 [zram] devattrshow+0x28/0x80 sysfskfseqshow+0x90/0x140 kernfsseqshow+0x34/0x48 seqreaditer+0x1d4/0x4e8 kernfsfopreaditer+0x40/0x58 newsyncread+0x9c/0x168 vfsread+0x1a8/0x1f8 ksysread+0x74/0x108 _arm64sysread+0x24/0x38 invokesyscall+0x50/0x120 el0svccommon.constprop.0+0xc8/0xf0 doel0svc+0x24/0x38 el0svc+0x38/0x138 el0t64synchandler+0xc0/0xc8 el0t64sync+0x188/0x190

The zram->compalgs[ZRAMPRIMARYCOMP] can be NULL in zramadd() if compalgorithmset() has not been called. User can access the zram device by sysfs after deviceadddisk(), so there is a time window to trigger the NULL pointer dereference. Move it ahead deviceadddisk() to make sure when user can access the zram device, it is ready. compalgorithmset() is protected by zram->init_lock in other places and no such problem.(CVE-2024-53222)

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

nilfs2: prevent use of deleted inode

syzbot reported a WARNING in nilfs_rmdir. [1]

Because the inode bitmap is corrupted, an inode with an inode number that should exist as a ".nilfs" file was reassigned by nilfsmkdir for "file0", causing an inode duplication during execution. And this causes an underflow of inlink in rmdir operations.

The inode is used twice by the same task to unmount and remove directories ".nilfs" and "file0", it trigger warning in nilfs_rmdir.

Avoid to this issue, check inlink in nilfsiget(), if it is 0, it means that this inode has been deleted, and iput is executed to reclaim it.

[1] WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 dropnlink+0xc4/0x110 fs/inode.c:407 ... Call Trace: <TASK> nilfsrmdir+0x1b0/0x250 fs/nilfs2/namei.c:342 vfsrmdir+0x3a3/0x510 fs/namei.c:4394 dormdir+0x3b5/0x580 fs/namei.c:4453 _dosysrmdir fs/namei.c:4472 [inline] _sesysrmdir fs/namei.c:4470 [inline] _x64sysrmdir+0x47/0x50 fs/namei.c:4470 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-53690)

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

drm: adv7511: Fix use-after-free in adv7533attachdsi()

The hostnode pointer was assigned and freed in adv7533parsedt(), and later, adv7533attachdsi() uses the same. Fix this use-after-free issue by dropping ofnodeput() in adv7533parsedt() and calling ofnode_put() in error path of probe() and also in the remove().(CVE-2024-57887)

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

ALSA: seq: oss: Fix races at processing SysEx messages

OSS sequencer handles the SysEx messages split in 6 bytes packets, and ALSA sequencer OSS layer tries to combine those. It stores the data in the internal buffer and this access is racy as of now, which may lead to the out-of-bounds access.

As a temporary band-aid fix, introduce a mutex for serializing the process of the SysEx message packets.(CVE-2024-57893)

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

iio: light: vcnl4035: fix information leak in triggered buffer

The 'buffer' local array is used to push data to userspace from a triggered buffer, but it does not set an initial value for the single data element, which is an u16 aligned to 8 bytes. That leaves at least 4 bytes uninitialized even after writing an integer value with regmap_read().

Initialize the array to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57910)