OESA-2024-1541

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

pstore/ram: Fix crash when setting number of cpus to an odd number

When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zonesize addr of zone2 = BASE + zonesize*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va.

So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug.(CVE-2023-52619)

A race condition was found in the Linux kernel's bluetooth device driver in {min,max}keysize_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

(CVE-2024-24860)

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:

ip6tunnel: fix NEXTHDRFRAGMENT handling in ip6tnlparsetlvenc_lim()

syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.

Reading frag_off can only be done if we pulled enough bytes to skb->head. Currently we might access garbage.

[1] BUG: KMSAN: uninit-value in ip6tnlparsetlvenclim+0x94f/0xbb0 ip6tnlparsetlvenclim+0x94f/0xbb0 ipxip6tnlxmit net/ipv6/ip6tunnel.c:1326 [inline] ip6tnlstartxmit+0xab2/0x1a70 net/ipv6/ip6tunnel.c:1432 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 _devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] neighconnectedoutput+0x569/0x660 net/core/neighbour.c:1592 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x23a9/0x2b30 net/ipv6/ip6output.c:137 ip6finishoutput+0x855/0x12b0 net/ipv6/ip6output.c:222 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x323/0x610 net/ipv6/ip6output.c:243 dstoutput include/net/dst.h:451 [inline] ip6localout+0xe9/0x140 net/ipv6/outputcore.c:155 ip6sendskb net/ipv6/ip6output.c:1952 [inline] ip6pushpendingframes+0x1f9/0x560 net/ipv6/ip6output.c:1972 rawv6pushpendingframes+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inetsendmsg+0x105/0x190 net/ipv4/afinet.c:847 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 _syssendmsg+0x28d/0x3c0 net/socket.c:2638 _syssendmsg net/socket.c:2667 [inline] _dosyssendmsg net/socket.c:2676 [inline] _sesyssendmsg net/socket.c:2674 [inline] _x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x63/0x6b

Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5c9/0x970 mm/slub.c:3517 _dokmallocnode mm/slabcommon.c:1006 [inline] _kmallocnodetrackcaller+0x118/0x3c0 mm/slabcommon.c:1027 kmallocreserve+0x249/0x4a0 net/core/skbuff.c:582 pskbexpandhead+0x226/0x1a00 net/core/skbuff.c:2098 _pskbpulltail+0x13b/0x2310 net/core/skbuff.c:2655 pskbmaypullreason include/linux/skbuff.h:2673 [inline] pskbmaypull include/linux/skbuff.h:2681 [inline] ip6tnlparsetlvenclim+0x901/0xbb0 net/ipv6/ip6tunnel.c:408 ipxip6tnlxmit net/ipv6/ip6tunnel.c:1326 [inline] ip6tnlstartxmit+0xab2/0x1a70 net/ipv6/ip6tunnel.c:1432 _netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 _devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] neighconnectedoutput+0x569/0x660 net/core/neighbour.c:1592 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x23a9/0x2b30 net/ipv6/ip6output.c:137 ip6finishoutput+0x855/0x12b0 net/ipv6/ip6output.c:222 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x323/0x610 net/ipv6/ip6output.c:243 dstoutput include/net/dst.h:451 [inline] ip6localout+0xe9/0x140 net/ipv6/outputcore.c:155 ip6sendskb net/ipv6/ip6output.c:1952 [inline] ip6pushpendingframes+0x1f9/0x560 net/ipv6/ip6output.c:1972 rawv6pushpendingframes+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inetsendmsg+0x105/0x190 net/ipv4/afinet.c:847 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2584 _syssendmsg+0x28d/0x3c0 net/socket.c:2638 _syssendmsg net/socket.c:2667 [inline] _dosys_sendms ---truncated---(CVE-2024-26633)

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:

aoe: fix the potential use-after-free problem in aoecmdcfgpkts

This patch is against CVE-2023-6270. The description of cve is:

A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmdcfgpkts() function improperly updates the refcnt on struct net_device, and a use-after-free can be triggered by racing between the free on the struct and the access through the skbtxq global queue. This could lead to a denial of service condition or potential code execution.

In aoecmdcfgpkts(), it always calls devput(ifp) when skb initial code is finished. But the netdevice ifp will still be used in later tx()->devqueuexmit() in kthread. Which means that the devput(ifp) should NOT be called in the success path of skb initial code in aoecmdcfgpkts(). Otherwise tx() may run into use-after-free because the netdevice is freed.

This patch removed the devput(ifp) in the success path in aoecmdcfgpkts(), and added devput() after skb xmit in tx().(CVE-2024-26898)

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

RDMA/mlx5: Fix fortify source warning while accessing Eth segment

------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inlinehdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5ibpostsend+0x191b/0x1a60 [mlx5ib] Modules linked in: 8021q garp mrp stp llc rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) ibumad(OE) mlx5ib(OE) ibuverbs(OE) ibcore(OE) mlx5core(OE) pcihypervintf mlxdevm(OE) mlxcompat(OE) tls mlxfw(OE) psample nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables libcrc32c nfnetlink mstpciconf(OE) knem(OE) vfiopci vfiopcicore vfioiommutype1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrmuser xfrmalgo ipmidevintf ipmimsghandler binfmtmisc crct10difpclmul crc32pclmul polyvalclmulni polyvalgeneric ghashclmulniintel sha512ssse3 sndpcsp aesniintel cryptosimd cryptd sndpcm sndtimer joydev snd soundcore inputleds serioraw evbug nfsd authrpcgss nfsacl lockd grace schfqcodel sunrpc drm efipstore iptables xtables autofs4 psmouse virtionet netfailover failover floppy [last unloaded: mlxcompat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5ibpostsend+0x191b/0x1a60 [mlx5ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? showregs+0x72/0x90 ? mlx5ibpostsend+0x191b/0x1a60 [mlx5ib] ? _warn+0x8d/0x160 ? mlx5ibpostsend+0x191b/0x1a60 [mlx5ib] ? reportbug+0x1bb/0x1d0 ? handlebug+0x46/0x90 ? excinvalidop+0x19/0x80 ? asmexcinvalidop+0x1b/0x20 ? mlx5ibpostsend+0x191b/0x1a60 [mlx5ib] mlx5ibpostsendnodrain+0xb/0x20 [mlx5ib] ipoibsend+0x2ec/0x770 [ibipoib] ipoibstartxmit+0x5a0/0x770 [ibipoib] devhardstartxmit+0x8e/0x1e0 ? validatexmitskblist+0x4d/0x80 schdirectxmit+0x116/0x3a0 _devxmitskb+0x1fd/0x580 _devqueuexmit+0x284/0x6b0 ? _rawspinunlockirq+0xe/0x50 ? _flushwork.isra.0+0x20d/0x370 ? pushpseudoheader+0x17/0x40 [ibipoib] neighconnectedoutput+0xcd/0x110 ipfinishoutput2+0x179/0x480 ? _smpcallsinglequeue+0x61/0xa0 _ipfinishoutput+0xc3/0x190 ipfinishoutput+0x2e/0xf0 ipoutput+0x78/0x110 ? _pfxipfinishoutput+0x10/0x10 iplocalout+0x64/0x70 _ipqueuexmit+0x18a/0x460 ipqueuexmit+0x15/0x30 _tcptransmitskb+0x914/0x9c0 tcpwritexmit+0x334/0x8d0 tcppushone+0x3c/0x60 tcpsendmsglocked+0x2e1/0xac0 tcpsendmsg+0x2d/0x50 inetsendmsg+0x43/0x90 socksendmsg+0x68/0x80 sockwriteiter+0x93/0x100 vfswrite+0x326/0x3c0 ksyswrite+0xbd/0xf0 ? dosyscall64+0x69/0x90 _x64syswrite+0x19/0x30 dosyscall_ ---truncated---(CVE-2024-26907)

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)