OESA-2024-2217

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ALSA: line6: Fix racy access to midibuf

There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here).

This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.(CVE-2024-44954)

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

sched/smt: Fix unbalance schedsmtpresent dec/inc

I got the following warn report while doing stress test:

jump label: negative count! WARNING: CPU: 3 PID: 38 at kernel/jumplabel.c:263 statickeyslowtrydec+0x9d/0xb0 Call Trace: <TASK> _statickeyslowdeccpuslocked+0x16/0x70 schedcpudeactivate+0x26e/0x2a0 cpuhpinvokecallback+0x3ad/0x10d0 cpuhpthreadfun+0x3f5/0x680 smpbootthreadfn+0x56d/0x8d0 kthread+0x309/0x400 retfromfork+0x41/0x70 retfromfork_asm+0x1b/0x30 </TASK>

Because when cpusetcpuinactive() fails in schedcpudeactivate(), the cpu offline failed, but schedsmtpresent is decremented before calling schedcpudeactivate(), it leads to unbalanced dec/inc, so fix it by incrementing schedsmtpresent in the error path.(CVE-2024-44958)

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

memcgwriteevent_control(): fix a user-triggerable oops

we are not guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane).(CVE-2024-45021)

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

scsi: aacraid: Fix double-free on probe failure

aacprobeone() calls hardware-specific init functions through the aacdriverident::init pointer, all of which eventually call down to aacinitadapter().

If aacinitadapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member.

After the hardware-specific init function returns an error, aacprobeone() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)

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

usb: dwc3: st: fix probed platform device ref count on probe error path

The probe function never performs any paltform device allocation, thus error path "undoplatformdev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources.(CVE-2024-46674)

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

apparmor: fix possible NULL pointer dereference

profile->parent->dents[AAFSPROFDIR] could be NULL only if its parent is made from _createmissingancestors(..) and 'ent->old' is NULL in aareplace_profiles(..). In that case, it must return an error code and the code, -ENOENT represents its state that the path of its parent is not existed yet.

BUG: kernel NULL pointer dereference, address: 0000000000000030 PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 3362 Comm: apparmorparser Not tainted 6.8.0-24-generic #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:aafscreate.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0 Call Trace: <TASK> ? showregs+0x6d/0x80 ? _die+0x24/0x80 ? pagefaultoops+0x99/0x1b0 ? kernelmodefixuporoops+0xb2/0x140 ? _badareanosemaphore+0x1a5/0x2c0 ? findvma+0x34/0x60 ? badareanosemaphore+0x16/0x30 ? douseraddrfault+0x2a2/0x6b0 ? excpagefault+0x83/0x1b0 ? asmexcpagefault+0x27/0x30 ? aafscreate.constprop.0+0x7f/0x130 ? aafscreate.constprop.0+0x51/0x130 _aafsprofilemkdir+0x3d6/0x480 aareplaceprofiles+0x83f/0x1270 policyupdate+0xe3/0x180 profileload+0xbc/0x150 ? rwverifyarea+0x47/0x140 vfswrite+0x100/0x480 ? _x64sysopenat+0x55/0xa0 ? syscallexittousermode+0x86/0x260 ksyswrite+0x73/0x100 _x64syswrite+0x19/0x30 x64syscall+0x7e/0x25c0 dosyscall64+0x7f/0x180 entrySYSCALL64afterhwframe+0x78/0x80 RIP: 0033:0x7be9f211c574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574 RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004 RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80 R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 </TASK> Modules linked in: sndseqdummy sndhrtimer qrtr sndhdacodecgeneric sndhdaintel sndinteldspcfg sndintelsdwacpi sndhdacodec sndhdacore sndhwdep sndpcm sndseqmidi sndseqmidievent sndrawmidi sndseq sndseqdevice i2ci801 sndtimer i2csmbus qxl snd soundcore drmttmhelper lpcich ttm joydev inputleds serioraw machid binfmtmisc msr parportpc ppdev lp parport efipstore nfnetlink dmisysfs qemufwcfg iptables xtables autofs4 hidgeneric usbhid hid ahci libahci psmouse virtiorng xhcipci xhcipcirenesas CR2: 0000000000000030 ---[ end trace 0000000000000000 ]--- RIP: 0010:aafscreate.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000 ---truncated---(CVE-2024-46721)

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

drm/amdgpu: fix mc_data out-of-bounds read warning

Clear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)

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

VMCI: Fix use-after-free when removing resource in vmciresourceremove()

When removing a resource from vmciresourcetable in vmciresourceremove(), the search is performed using the resource handle by comparing context and resource fields.

It is possible though to create two resources with different types but same handle (same context and resource fields).

When trying to remove one of the resources, vmciresourceremove() may not remove the intended one, but the object will still be freed as in the case of the datagram type in vmcidatagramdestroyhandle(). vmciresource_table will still hold a pointer to this freed resource leading to a use-after-free vulnerability.

BUG: KASAN: use-after-free in vmcihandleisequal include/linux/vmwvmcidefs.h:142 [inline] BUG: KASAN: use-after-free in vmciresourceremove+0x3a1/0x410 drivers/misc/vmwvmci/vmciresource.c:147 Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x82/0xa9 lib/dumpstack.c:106 printaddressdescription.constprop.0+0x21/0x366 mm/kasan/report.c:239 _kasanreport.cold+0x7f/0x132 mm/kasan/report.c:425 kasanreport+0x38/0x51 mm/kasan/report.c:442 vmcihandleisequal include/linux/vmwvmcidefs.h:142 [inline] vmciresourceremove+0x3a1/0x410 drivers/misc/vmwvmci/vmciresource.c:147 vmciqpbrokerdetach+0x89a/0x11b9 drivers/misc/vmwvmci/vmciqueuepair.c:2182 ctxfreectx+0x473/0xbe1 drivers/misc/vmwvmci/vmcicontext.c:444 krefput include/linux/kref.h:65 [inline] vmcictxput drivers/misc/vmwvmci/vmcicontext.c:497 [inline] vmcictxdestroy+0x170/0x1d6 drivers/misc/vmwvmci/vmcicontext.c:195 vmcihostclose+0x125/0x1ac drivers/misc/vmwvmci/vmcihost.c:143 _fput+0x261/0xa34 fs/filetable.c:282 taskworkrun+0xf0/0x194 kernel/taskwork.c:164 tracehooknotifyresume include/linux/tracehook.h:189 [inline] exittousermodeloop+0x184/0x189 kernel/entry/common.c:187 exittousermodeprepare+0x11b/0x123 kernel/entry/common.c:220 _syscallexittousermodework kernel/entry/common.c:302 [inline] syscallexittousermode+0x18/0x42 kernel/entry/common.c:313 dosyscall64+0x41/0x85 arch/x86/entry/common.c:86 entrySYSCALL64after_hwframe+0x6e/0x0

This change ensures the type is also checked when removing the resource from vmciresourcetable in vmciresourceremove().(CVE-2024-46738)

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

uiohvgeneric: Fix kernel NULL pointer dereference in hvuiorescind

For primary VM Bus channels, primary_channel pointer is always NULL. This pointer is valid only for the secondary channels. Also, rescind callback is meant for primary channels only.

Fix NULL pointer dereference by retrieving the device_obj from the parent for the primary channel.(CVE-2024-46739)

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

binder: fix UAF caused by offsets overwrite

Binder objects are processed and copied individually into the target buffer during transactions. Any raw data in-between these objects is copied as well. However, this raw data copy lacks an out-of-bounds check. If the raw data exceeds the data section size then the copy overwrites the offsets section. This eventually triggers an error that attempts to unwind the processed objects. However, at this point the offsets used to index these objects are now corrupted.

Unwinding with corrupted offsets can result in decrements of arbitrary nodes and lead to their premature release. Other users of such nodes are left with a dangling pointer triggering a use-after-free. This issue is made evident by the following KASAN report (trimmed):

================================================================== BUG: KASAN: slab-use-after-free in rawspin_lock+0xe4/0x19c Write of size 4 at addr ffff47fc91598f04 by task binder-util/743

CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1 Hardware name: linux,dummy-virt (DT) Call trace: rawspinlock+0xe4/0x19c binderfreebuf+0x128/0x434 binderthreadwrite+0x8a4/0x3260 binderioctl+0x18f0/0x258c [...]

Allocated by task 743: _kmalloccachenoprof+0x110/0x270 bindernewnode+0x50/0x700 bindertransaction+0x413c/0x6da8 binderthreadwrite+0x978/0x3260 binder_ioctl+0x18f0/0x258c [...]

Freed by task 745: kfree+0xbc/0x208 binderthreadread+0x1c5c/0x37d4 binder_ioctl+0x16d8/0x258c [...] ==================================================================

To avoid this issue, let's check that the raw data copy is within the boundaries of the data section.(CVE-2024-46740)

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

PCI: Add missing bridge lock to pcibuslock()

One of the true positives that the cfgaccesslock lockdep effort identified is this sequence:

WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pcibridgesecondarybusreset+0x5d/0x70 RIP: 0010:pcibridgesecondarybusreset+0x5d/0x70 Call Trace: <TASK> ? _warn+0x8c/0x190 ? pcibridgesecondarybusreset+0x5d/0x70 ? reportbug+0x1f8/0x200 ? handlebug+0x3c/0x70 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? pcibridgesecondarybusreset+0x5d/0x70 pciresetbus+0x1d8/0x270 vmdprobe+0x778/0xa10 pcidevice_probe+0x95/0x120

Where pciresetbus() users are triggering unlocked secondary bus resets. Ironically pcibusreset(), several calls down from pciresetbus(), uses pcibuslock() before issuing the reset which locks everything but the bridge itself.

For the same motivation as adding:

bridge = pciupstreambridge(dev); if (bridge) pcidevlock(bridge);

to pciresetfunction() for the "bus" and "cxlbus" reset cases, add pcidevlock() for @bus->self to pcibus_lock().

bhelgaas: squash in recursive locking deadlock fix from Keith Busch: https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com

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

hwmon: (w83627ehf) Fix underflows seen when writing limit attributes

DIVROUNDCLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clampval() and DIVROUND_CLOSEST() operations.(CVE-2024-46756)

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

hwmon: (lm95234) Fix underflows seen when writing limit attributes

DIVROUNDCLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clampval() and DIVROUND_CLOSEST() operations.(CVE-2024-46758)

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

pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv

The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel crash when we try to hot-unplug/disable the PCIe switch/bridge from the PHB.

The crash occurs because although the MSI data structure has been released during disable/hot-unplug path and it has been assigned with NULL, still during unregistration the code was again trying to explicitly disable the MSI which causes the NULL pointer dereference and kernel crash.

The patch fixes the check during unregistration path to prevent invoking pcidisablemsi/msix() since its data structure is already freed.(CVE-2024-46761)

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

can: bcm: Remove proc entry when dev is unregistered.

syzkaller reported a warning in bcm_connect() below. [0]

The repro calls connect() to vxcan1, removes vxcan1, and calls connect() with ifindex == 0.

Calling connect() for a BCM socket allocates a proc entry. Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().

However, removing the bound device resets bcmsk(sk)->bound to 0 in bcmnotify().

The 2nd connect() tries to allocate a proc entry with the same name and sets NULL to bcmsk(sk)->bcmproc_read, leaking the original proc entry.

Since the proc entry is available only for connect()ed sockets, let's clean up the entry when the bound netdev is unregistered.

WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 procregister+0x645/0x8f0 fs/proc/generic.c:375 Modules linked in: CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:procregister+0x645/0x8f0 fs/proc/generic.c:375 Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48 RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246 RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002 RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0 R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec FS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> proccreatenetsingle+0x144/0x210 fs/proc/procnet.c:220 bcmconnect+0x472/0x840 net/can/bcm.c:1673 _sysconnectfile net/socket.c:2049 [inline] _sysconnect+0x5d2/0x690 net/socket.c:2066 _dosysconnect net/socket.c:2076 [inline] _sesysconnect net/socket.c:2073 [inline] _x64sysconnect+0x8f/0x100 net/socket.c:2073 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1c0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7fbd708b0e5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 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 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040 R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098 R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 </TASK> removeprocentry: removing non-empty directory 'net/can-bcm', leaking at least '2456'(CVE-2024-46771)

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

udf: Avoid excessive partition lengths

Avoid mounting filesystems where the partition would overflow the 32-bits used for block number. Also refuse to mount filesystems where the partition length is so large we cannot safely index bits in a block bitmap.(CVE-2024-46777)

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

nilfs2: protect references to superblock parameters exposed in sysfs

The superblock buffers of nilfs2 can not only be overwritten at runtime for modifications/repairs, but they are also regularly swapped, replaced during resizing, and even abandoned when degrading to one side due to backing device issues. So, accessing them requires mutual exclusion using the reader/writer semaphore "nilfs->ns_sem".

Some sysfs attribute show methods read this superblock buffer without the necessary mutual exclusion, which can cause problems with pointer dereferencing and memory access, so fix it.(CVE-2024-46780)

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

nilfs2: fix missing cleanup on rollforward recovery error

In an error injection test of a routine for mount-time recovery, KASAN found a use-after-free bug.

It turned out that if data recovery was performed using partial logs created by dsync writes, but an error occurred before starting the log writer to create a recovered checkpoint, the inodes whose data had been recovered were left in the nsdirtyfiles list of the nilfs object and were not freed.

Fix this issue by cleaning up inodes that have read the recovery data if the recovery routine fails midway before the log writer starts.(CVE-2024-46781)