OESA-2025-1067

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix out of bounds reads when finding clock sources The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads. For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop. For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.(CVE-2024-53150)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix uninitialized value in ocfs2filereaditer() Syzbot has reported the following KMSAN splat: BUG: KMSAN: uninit-value in ocfs2filereaditer+0x9a4/0xf80 ocfs2filereaditer+0x9a4/0xf80 ioread+0x8d4/0x20f0 ioread+0x3e/0xf0 ioissuesqe+0x42b/0x22c0 iowqsubmitwork+0xaf9/0xdc0 ioworkerhandlework+0xd13/0x2110 iowqworker+0x447/0x1410 retfromfork+0x6f/0x90 retfromforkasm+0x1a/0x30 Uninit was created at: _allocpagesnoprof+0x9a7/0xe00 allocpagesmpolnoprof+0x299/0x990 allocpagesnoprof+0x1bf/0x1e0 allocateslab+0x33a/0x1250 _slaballoc+0x12ef/0x35e0 kmemcacheallocbulknoprof+0x486/0x1330 _ioallocreqrefill+0x84/0x560 iosubmitsqes+0x172f/0x2f30 _sesysiouringenter+0x406/0x41c0 _x64sysiouringenter+0x11f/0x1a0 x64syscall+0x2b54/0x3ba0 dosyscall64+0xcd/0x1e0 entrySYSCALL64afterhwframe+0x77/0x7f Since an instance of 'struct kiocb' may be passed from the block layer with 'private' field uninitialized, introduce 'ocfs2iocbinitrwlocked()' and use it from where 'ocfs2dioendio()' might take care, i.e. in 'ocfs2filereaditer()' and 'ocfs2filewrite_iter()'.(CVE-2024-53155)

In the Linux kernel, the following vulnerability has been resolved: firmware: armscpi: Check the DVFS OPP count returned by the firmware Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero. dvfsinfo.oppcount may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info->count, sizeof(*opp), GFPKERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpidvfsrecalcrate+0x40/0x58 [clkscpi] | lr : clkregister+0x438/0x720 | Call trace: | scpidvfsrecalcrate+0x40/0x58 [clkscpi] | devmclkhwregister+0x50/0xa0 | scpiclkopsinit.isra.2+0xa0/0x138 [clkscpi] | scpiclocksprobe+0x528/0x70c [clkscpi] | platformdrvprobe+0x58/0xa8 | reallyprobe+0x260/0x3d0 | driverprobedevice+0x12c/0x148 | devicedriverattach+0x74/0x98 | _driverattach+0xb4/0xe8 | busforeachdev+0x88/0xe0 | driverattach+0x30/0x40 | busadddriver+0x178/0x2b0 | driverregister+0x64/0x118 | _platformdriverregister+0x54/0x60 | scpiclocksdriverinit+0x24/0x1000 [clkscpi] | dooneinitcall+0x54/0x220 | doinitmodule+0x54/0x1c8 | loadmodule+0x14a4/0x1668 | _sesysfinitmodule+0xf8/0x110 | _arm64sysfinitmodule+0x24/0x30 | el0svccommon+0x78/0x170 | el0svchandler+0x38/0x78 | el0svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none(CVE-2024-53157)

In the Linux kernel, the following vulnerability has been resolved: ovl: Filter invalid inodes with missing lookup function Add a check to the ovldentryweird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack.(CVE-2024-56570)

In the Linux kernel, the following vulnerability has been resolved: net: afcan: do not leave a dangling sk pointer in cancreate() On error cancreate() frees the allocated sk object, but sockinit_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential out-of-bounds memory access in nilfsfindentry() Syzbot reported that when searching for records in a directory where the inode's isize is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled. This is because nilfslastbyte(), which is called by nilfsfindentry() and others to calculate the number of valid bytes of directory data in a page from isize and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the isize value is assigned. This caused a large byte offset value due to underflow in the end address calculation in the calling nilfsfindentry(), resulting in memory access that exceeds the folio/page size. Fix this issue by changing the type of the local variable causing the bit loss from "unsigned int" to "u64". The return value of nilfslastbyte() is also of type "unsigned int", but it is truncated so as not to exceed PAGESIZE and no bit loss occurs, so no change is required.(CVE-2024-56619)

In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free of kernel socket in cleanupbearer(). syzkaller reported a use-after-free of UDP kernel socket in cleanupbearer() without repro. [0][1] When bearerdisable() calls tipcudpdisable(), cleanup of the UDP kernel socket is deferred by work calling cleanupbearer(). tipcnetstop() waits for such works to finish by checking tipcnet(net)->wqcount. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanupnet() and resulting in use-after-free. Let's move the decrement after releasing the socket in cleanupbearer(). [0]: reftracker: net notrefcnt@000000009b3d1faf has 1/1 users at skalloc+0x438/0x608 inetcreate+0x4c8/0xcb0 sockcreate+0x350/0x6b8 sockcreatekern+0x58/0x78 udpsockcreate4+0x68/0x398 udpsockcreate+0x88/0xc8 tipcudpenable+0x5e8/0x848 _tipcnlbearerenable+0x84c/0xed8 tipcnlbearerenable+0x38/0x60 genlfamilyrcvmsgdoit+0x170/0x248 genlrcvmsg+0x400/0x5b0 netlinkrcvskb+0x1dc/0x398 genlrcv+0x44/0x68 netlinkunicast+0x678/0x8b0 netlinksendmsg+0x5e4/0x898 syssendmsg+0x500/0x830 [1]: BUG: KMSAN: use-after-free in udphashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udplibunhash+0x3b8/0x930 net/ipv4/udp.c:1979 udphashslot include/net/udp.h:85 [inline] udplibunhash+0x3b8/0x930 net/ipv4/udp.c:1979 skcommonrelease+0xaf/0x3f0 net/core/sock.c:3820 inetrelease+0x1e0/0x260 net/ipv4/afinet.c:437 inet6release+0x6f/0xd0 net/ipv6/afinet6.c:489 _sockrelease net/socket.c:658 [inline] sockrelease+0xa0/0x210 net/socket.c:686 cleanupbearer+0x42d/0x4c0 net/tipc/udpmedia.c:819 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xcaf/0x1c90 kernel/workqueue.c:3310 workerthread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 retfromfork+0x60/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry64.S:244 Uninit was created at: slabfreehook mm/slub.c:2269 [inline] slabfree mm/slub.c:4580 [inline] kmemcachefree+0x207/0xc40 mm/slub.c:4682 netfree net/core/netnamespace.c:454 [inline] cleanupnet+0x16f2/0x19d0 net/core/netnamespace.c:647 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xcaf/0x1c90 kernel/workqueue.c:3310 workerthread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 retfromfork+0x60/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry64.S:244 CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanupbearer(CVE-2024-56642)

In the Linux kernel, the following vulnerability has been resolved: acpi: nfit: vmalloc-out-of-bounds Read in acpinfitctl Fix an issue detected by syzbot with KASAN: BUG: KASAN: vmalloc-out-of-bounds in cmdtofunc drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpinfitctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459 The issue occurs in cmdtofunc when the callpkg->ndreserved2 array is accessed without verifying that callpkg points to a buffer that is appropriately sized as a struct ndcmdpkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space. To address this, a check was added in acpinfitctl() to ensure that buf is not NULL and that buflen is less than sizeof(*callpkg) before accessing it. This ensures safe access to the members of callpkg, including the nd_reserved2 array.(CVE-2024-56662)

In the Linux kernel, the following vulnerability has been resolved: rtc: check if _rtcreadtime was successful in rtctimerdowork() If the _rtcreadtime call fails,, the struct rtctime tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtctmtoktime later, the result may be a very large value (possibly KTIMEMAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup.(CVE-2024-56739)