OESA-2024-1524

The Linux Kernel, the operating system core itself.

Security Fix(es):

createemptylvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->leb_size.(CVE-2024-25739)

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

drm/bridge: sii902x: Fix probing race issue

A null pointer dereference crash has been observed rarely on TI platforms using sii9022 bridge:

[ 53.271356] sii902xgetedid+0x34/0x70 [sii902x] [ 53.276066] sii902xbridgegetedid+0x14/0x20 [sii902x] [ 53.281381] drmbridgegetedid+0x20/0x34 [drm] [ 53.286305] drmbridgeconnectorgetmodes+0x8c/0xcc [drmkmshelper] [ 53.292955] drmhelperprobesingleconnectormodes+0x190/0x538 [drmkmshelper] [ 53.300510] drmclientmodesetprobe+0x1f0/0xbd4 [drm] [ 53.305958] _drmfbhelperinitialconfigandunlock+0x50/0x510 [drmkmshelper] [ 53.313611] drmfbhelperinitialconfig+0x48/0x58 [drmkmshelper] [ 53.320039] drmfbdevdmaclienthotplug+0x84/0xd4 [drmdmahelper] [ 53.326401] drmclientregister+0x5c/0xa0 [drm] [ 53.331216] drmfbdevdmasetup+0xc8/0x13c [drmdmahelper] [ 53.336881] tidssprobe+0x128/0x264 [tidss] [ 53.341174] platformprobe+0x68/0xc4 [ 53.344841] reallyprobe+0x188/0x3c4 [ 53.348501] _driverprobedevice+0x7c/0x16c [ 53.352854] driverprobedevice+0x3c/0x10c [ 53.357033] _deviceattachdriver+0xbc/0x158 [ 53.361472] busforeachdrv+0x88/0xe8 [ 53.365303] _deviceattach+0xa0/0x1b4 [ 53.369135] deviceinitialprobe+0x14/0x20 [ 53.373314] busprobedevice+0xb0/0xb4 [ 53.377145] deferredprobeworkfunc+0xcc/0x124 [ 53.381757] processonework+0x1f0/0x518 [ 53.385770] workerthread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] retfromfork+0x10/0x20

The issue here is as follows:

• tidss probes, but is deferred as sii902x is still missing.
• sii902x starts probing and enters sii902x_init().
• sii902x calls drmbridgeadd(). Now the sii902x bridge is ready from DRM's perspective.
• sii902x calls sii902xaudiocodecinit() and platformdeviceregisterdata()
• The registration of the audio platform device causes probing of the deferred devices.
• tidss probes, which eventually causes sii902xbridgeget_edid() to be called.
• sii902xbridgeget_edid() tries to use the i2c to read the edid. However, the sii902x driver has not set up the i2c part yet, leading to the crash.

Fix this by moving the drmbridgeadd() to the end of the sii902xinit(), which is also at the very end of sii902xprobe().(CVE-2024-26607)

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

tcp: make sure init the accept_queue's spinlocks once

When I run syz's reproduction C program locally, it causes the following issue: pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at pvqueuedspinunlockslowpath (kernel/locking/qspinlockparavirt.h:508) Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:pvqueuedspinunlockslowpath (kernel/locking/qspinlockparavirt.h:508) Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> rawspinunlock (kernel/locking/spinlock.c:186) inetcskreqskqueueadd (net/ipv4/inetconnectionsock.c:1321) inetcskcompletehashdance (net/ipv4/inetconnectionsock.c:1358) tcpcheckreq (net/ipv4/tcpminisocks.c:868) tcpv4rcv (net/ipv4/tcpipv4.c:2260) ipprotocoldeliverrcu (net/ipv4/ipinput.c:205) iplocaldeliverfinish (net/ipv4/ipinput.c:234) _netifreceiveskbonecore (net/core/dev.c:5529) processbacklog (./include/linux/rcupdate.h:779) _napipoll (net/core/dev.c:6533) netrxaction (net/core/dev.c:6604) _dosoftirq (./arch/x86/include/asm/jumplabel.h:27) dosoftirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> _localbhenableip (kernel/softirq.c:381) _devqueuexmit (net/core/dev.c:4374) ipfinishoutput2 (./include/net/neighbour.h:540 net/ipv4/ipoutput.c:235) _ipqueuexmit (net/ipv4/ipoutput.c:535) _tcptransmitskb (net/ipv4/tcpoutput.c:1462) tcprcvsynsentstateprocess (net/ipv4/tcpinput.c:6469) tcprcvstateprocess (net/ipv4/tcpinput.c:6657) tcpv4dorcv (net/ipv4/tcpipv4.c:1929) _releasesock (./include/net/sock.h:1121 net/core/sock.c:2968) releasesock (net/core/sock.c:3536) inetwaitforconnect (net/ipv4/afinet.c:609) _inetstreamconnect (net/ipv4/afinet.c:702) inetstreamconnect (net/ipv4/afinet.c:748) _sysconnect (./include/linux/file.h:45 net/socket.c:2064) _x64sysconnect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) dosyscall64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:129) RIP: 0033:0x7fa10ff05a3d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20 </TASK>

The issue triggering process is analyzed as follows: Thread A Thread B tcpv4rcv //receive ack TCP packet inetshutdown tcpcheckreq tcpdisconnect //disconnect sock ... tcpsetstate(sk, TCPCLOSE) inetcskcompletehashdance ... inetcskreqskqueueadd
---truncated---(CVE-2024-26614)

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

btrfs: don't abort filesystem when attempting to snapshot deleted subvolume

If the source file descriptor to the snapshot ioctl refers to a deleted subvolume, we get the following abort:

BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 creatependingsnapshot+0x1040/0x1190 [btrfs] Modules linked in: pataacpi btrfs atapiix libata scsimod virtionet blake2bgeneric xor netfailover virtiorng failover scsicommon rngcore raid6pq libcrc32c CPU: 0 PID: 833 Comm: tsnapshotdele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:creatependingsnapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Call Trace: <TASK> ? creatependingsnapshot+0x1040/0x1190 [btrfs] ? _warn+0x81/0x130 ? creatependingsnapshot+0x1040/0x1190 [btrfs] ? reportbug+0x171/0x1a0 ? handlebug+0x3a/0x70 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? creatependingsnapshot+0x1040/0x1190 [btrfs] ? creatependingsnapshot+0x1040/0x1190 [btrfs] creatependingsnapshots+0x92/0xc0 [btrfs] btrfscommittransaction+0x66b/0xf40 [btrfs] btrfsmksubvol+0x301/0x4d0 [btrfs] btrfsmksnapshot+0x80/0xb0 [btrfs] _btrfsioctlsnapcreate+0x1c2/0x1d0 [btrfs] btrfsioctlsnapcreatev2+0xc4/0x150 [btrfs] btrfsioctl+0x8a6/0x2650 [btrfs] ? kmemcachefree+0x22/0x340 ? dosysopenat2+0x97/0xe0 _x64sysioctl+0x97/0xd0 dosyscall64+0x46/0xf0 entrySYSCALL64afterhwframe+0x6e/0x76 RIP: 0033:0x7fe20abe83af RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS: error (device vdc: state A) in creatependingsnapshot:1875: errno=-2 No such entry BTRFS info (device vdc: state EA): forced readonly BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction. BTRFS: error (device vdc: state EA) in cleanuptransaction:2055: errno=-2 No such entry

This happens because creatependingsnapshot() initializes the new root item as a copy of the source root item. This includes the refs field, which is 0 for a deleted subvolume. The call to btrfsinsertroot() therefore inserts a root with refs == 0. btrfsgetnewfsroot() then finds the root and returns -ENOENT if refs == 0, which causes creatependingsnapshot() to abort.

Fix it by checking the source root's refs before attempting the snapshot, but after locking subvol_sem to avoid racing with deletion.(CVE-2024-26644)

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

hvnetvsc: Fix race condition between netvscprobe and netvsc_remove

In commit ac5047671758 ("hvnetvsc: Disable NAPI before closing the VMBus channel"), napidisable was getting called for all channels, including all subchannels without confirming if they are enabled or not.

This caused hvnetvsc getting hung at napidisable, when netvscprobe() has finished running but nvdev->subchanwork has not started yet. netvscsubchanwork() -> rndissetsubchannel() has not created the sub-channels and because of that netvscscopen() is not running. netvscremove() calls cancelworksync(&nvdev->subchanwork), for which netvscsubchanwork did not run.

netifnapiadd() sets the bit NAPISTATESCHED because it ensures NAPI cannot be scheduled. Then netvscscopen() -> napienable will clear the NAPIFSTATESCHED bit, so it can be scheduled. napidisable() does the opposite.

Now during netvscdeviceremove(), when napidisable is called for those subchannels, napidisable gets stuck on infinite msleep.

This fix addresses this problem by ensuring that napidisable() is not getting called for non-enabled NAPI struct. But netifnapi_del() is still necessary for these non-enabled NAPI struct for cleanup purpose.

Call trace: [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002 [ 654.568030] Call Trace: [ 654.571221] <TASK> [ 654.573790] _schedule+0x2d6/0x960 [ 654.577733] schedule+0x69/0xf0 [ 654.581214] scheduletimeout+0x87/0x140 [ 654.585463] ? _bpftracetickstop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napidisable+0x2b/0x80 [ 654.597437] netvscdeviceremove+0x8a/0x1f0 [hvnetvsc] [ 654.603935] rndisfilterdeviceremove+0x194/0x1c0 [hvnetvsc] [ 654.611101] ? dowaitintr+0xb0/0xb0 [ 654.615753] netvscremove+0x7c/0x120 [hvnetvsc] [ 654.621675] vmbusremove+0x27/0x40 hvvmbus

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

afs: Increase buffer size in afsupdatevolume_status()

The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()

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

ARM: ep93xx: Add terminator to gpiodlookuptable

Without the terminator, if a conid is passed to gpiofind() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops.(CVE-2024-26751)

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

fs/aio: Restrict kiocbsetcancel_fn() to I/O submitted via libaio

If kiocbsetcancelfn() is called for I/O submitted via iouring, the following kernel warning appears:

WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocbsetcancelfn+0x9c/0xa8 Call trace: kiocbsetcancelfn+0x9c/0xa8 ffsepfilereaditer+0x144/0x1d0 ioread+0x19c/0x498 ioissuesqe+0x118/0x27c iosubmitsqes+0x25c/0x5fc _arm64sysiouringenter+0x104/0xab0 invokesyscall+0x58/0x11c el0svccommon+0xb4/0xf4 doel0svc+0x2c/0xb0 el0svc+0x2c/0xa4 el0t64synchandler+0x68/0xb4 el0t64sync+0x1a4/0x1a8

Fix this by setting the IOCBAIORW flag for read and write I/O that is submitted by libaio.(CVE-2024-26764)

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

ext4: avoid allocating blocks from corrupted group in ext4mbfindbygoal()

Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap.(CVE-2024-26772)

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

ext4: avoid allocating blocks from corrupted group in ext4mbtrybestfound()

Determine if the group block bitmap is corrupted before using acbex in ext4mbtrybestfound() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse.

ext4mbregularallocator ext4lockgroup(sb, group) ext4mbgoodgroup // check if the group bbitmap is corrupted ext4mbcomplexscangroup // Scan group gets acbex but doesn't use it ext4unlockgroup(sb, group) ext4markgroupbitmapcorrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4mbtrybestfound ext4lockgroup(ac->acsb, group) ext4mbusebestfound mbmark_used // Allocating blocks in block bitmap corrupted group(CVE-2024-26773)

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

fbdev: sis: Error out if pixclock equals zero

The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error.

In sisfbcheckvar(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning.

This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.(CVE-2024-26777)

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

fbdev: savage: Error out if pixclock equals zero

The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error.

Although pixclock is checked in savagefbdecodevar(), but it is not checked properly in savagefbprobe(). Fix this by checking whether pixclock is zero in the function savagefbcheck_var() before info->var.pixclock is used as the divisor.

This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.(CVE-2024-26778)

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

dmaengine: fsl-qdma: init irq after reg initialization

Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don't get processed by the irq handler before it is ready to and cause panic with the following trace:

Call trace: fslqdmaqueuehandler+0xf8/0x3e8 _handleirqeventpercpu+0x78/0x2b0 handleirqeventpercpu+0x1c/0x68 handleirqevent+0x44/0x78 handlefasteoiirq+0xc8/0x178 generichandleirq+0x24/0x38 _handledomainirq+0x90/0x100 gichandleirq+0x5c/0xb8 el1irq+0xb8/0x180 rawspinunlockirqrestore+0x14/0x40 _setupirq+0x4bc/0x798 requestthreadedirq+0xd8/0x190 devmrequestthreadedirq+0x74/0xe8 fslqdmaprobe+0x4d4/0xca8 platformdrvprobe+0x50/0xa0 reallyprobe+0xe0/0x3f8 driverprobedevice+0x64/0x130 devicedriverattach+0x6c/0x78 _driverattach+0xbc/0x158 busforeachdev+0x5c/0x98 driverattach+0x20/0x28 busadddriver+0x158/0x220 driverregister+0x60/0x110 _platformdriverregister+0x44/0x50 fslqdmadriverinit+0x18/0x20 dooneinitcall+0x48/0x258 kernelinitfreeable+0x1a4/0x23c kernelinit+0x10/0xf8 retfromfork+0x10/0x18(CVE-2024-26788)

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

vfio/pci: Lock external INTx masking ops

Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code.

In particular, irqtype is updated holding igate, therefore testing isintx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration.

This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows.(CVE-2024-26810)

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

bpf: Fix stackmap overflow check on 32-bit arches

The stackmap code relies on rounduppowoftwo() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAPHASH type, which contains the same check, copied from the hashtab code.

The commit in the fixes tag actually attempted to fix this, but the fix did not account for the UB, so the fix only works on CPUs where an overflow does result in a neat truncation to zero, which is not guaranteed. Checking the value before rounding does not have this problem.(CVE-2024-26883)

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

bpf: Fix hashtab overflow check on 32-bit arches

The hashtab code relies on rounduppowoftwo() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAPHASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup.(CVE-2024-26884)

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

bpf: Fix DEVMAP_HASH overflow check on 32-bit arches

The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end.

Syzbot managed to turn this into a crash on arm32 by creating a DEVMAPHASH with maxentries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation.(CVE-2024-26885)

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

vfio/pci: Disable auto-enable of exclusive INTx IRQ

Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio.

Instead, invert the logic using IRQFNOAUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.(CVE-2024-27437)