OESA-2024-1767

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

can: mcbausb: fix memory leak in mcbausb

Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS Analyzer Tool. The problem was in unfreed usb_coherent.

In mcbausbstart() 20 coherent buffers are allocated and there is nothing, that frees them:

1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URBFREEBUFFER is not set (see mcbausbstart) and this flag cannot be used with coherent buffers.

Fail log: | [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected | [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)

So, all allocated buffers should be freed with usbfreecoherent() explicitly

NOTE: The same pattern for allocating and freeing coherent buffers is used in drivers/net/can/usb/kvaserusb/kvaserusb_core.c(CVE-2021-47231)

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

can: j1939: fix Use-after-Free, hold skb ref while in use

This patch fixes a Use-after-Free found by the syzbot.

The problem is that a skb is taken from the per-session skb queue, without incrementing the ref count. This leads to a Use-after-Free if the skb is taken concurrently from the session queue due to a CTS.(CVE-2021-47232)

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

batman-adv: Avoid WARN_ON timing related checks

The soft/batadv interface for a queued OGM can be changed during the time the OGM was queued for transmission and when the OGM is actually transmitted by the worker.

But WARNON must be used to denote kernel bugs and not to print simple warnings. A warning can simply be printed using prwarn.(CVE-2021-47252)

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

media: ngene: Fix out-of-bounds bug in ngenecommandconfigfreebuf()

Fix an 11-year old bug in ngenecommandconfigfreebuf() while addressing the following warnings caught with -Warray-bounds:

arch/alpha/include/asm/string.h:22:16: warning: 'builtinmemcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string32.h:182:25: warning: 'builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]

The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member config of the wrong structue FWCONFIGUREBUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FWCONFIGUREFREEBUFFERS, instead, because it contains 6 more members apart from the header _hdr. Also, the name of the function ngenecommandconfigfreebuf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngenecommandconfig_buf(), above).

Fix this by enclosing those 6 members of struct FWCONFIGUREFREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy().

This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy().(CVE-2021-47288)

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

coresight: tmc-etf: Fix global-out-of-bounds in tmcupdateetf_buffer()

commit 6f755e85c332 ("coresight: Add helper for inserting synchronization packets") removed trailing '\0' from barrierpkt array and updated the call sites like etbupdatebuffer() to have proper checks for barrierpkt size before read but missed updating tmcupdateetfbuffer() which still reads barrierpkt past the array size resulting in KASAN out-of-bounds bug. Fix this by adding a check for barrierpkt size before accessing like it is done in etbupdate_buffer().

BUG: KASAN: global-out-of-bounds in tmcupdateetf_buffer+0x4b8/0x698 Read of size 4 at addr ffffffd05b7d1030 by task perf/2629

Call trace: dumpbacktrace+0x0/0x27c showstack+0x20/0x2c dumpstack+0x11c/0x188 printaddressdescription+0x3c/0x4a4 _kasanreport+0x140/0x164 kasanreport+0x10/0x18 _asanreportload4noabort+0x1c/0x24 tmcupdateetfbuffer+0x4b8/0x698 etmeventstop+0x248/0x2d8 etmeventdel+0x20/0x2c eventschedout+0x214/0x6f0 groupschedout+0xd0/0x270 ctxschedout+0x2ec/0x518 _perfeventtaskschedout+0x4fc/0xe6c _schedule+0x1094/0x16a0 preemptscheduleirq+0x88/0x170 arm64preemptscheduleirq+0xf0/0x18c el1irq+0xe8/0x180 perfeventexec+0x4d8/0x56c setupnewexec+0x204/0x400 loadelfbinary+0x72c/0x18c0 searchbinaryhandler+0x13c/0x420 loadscript+0x500/0x6c4 searchbinaryhandler+0x13c/0x420 execbinprm+0x118/0x654 _doexecvefile+0x77c/0xba4 _arm64compatsysexecve+0x98/0xac el0svccommon+0x1f8/0x5e0 el0svccompathandler+0x84/0xb0 el0svc_compat+0x10/0x50

The buggy address belongs to the variable: barrier_pkt+0x10/0x40

Memory state around the buggy address: ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03 ^ ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa ==================================================================(CVE-2021-47346)

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

wl1251: Fix possible buffer overflow in wl1251cmdscan

Function wl1251cmdscan calls memcpy without checking the length. Harden by checking the length is within the maximum allowed size.(CVE-2021-47347)

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

xhci: Fix command ring pointer corruption while aborting a command

The command ring pointer is located at [6:63] bits of the command ring control register (CRCR). All the control bits like command stop, abort are located at [0:3] bits. While aborting a command, we read the CRCR and set the abort bit and write to the CRCR. The read will always give command ring pointer as all zeros. So we essentially write only the control bits. Since we split the 64 bit write into two 32 bit writes, there is a possibility of xHC command ring stopped before the upper dword (all zeros) is written. If that happens, xHC updates the upper dword of its internal command ring pointer with all zeros. Next time, when the command ring is restarted, we see xHC memory access failures. Fix this issue by only writing to the lower dword of CRCR where all control bits are located.(CVE-2021-47434)

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

mm, slub: fix potential memoryleak in kmemcacheopen()

In error path, the randomseq of slub cache might be leaked. Fix this by using _kmemcacherelease() to release all the relevant resources.(CVE-2021-47466)

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

spi: Fix deadlock when adding SPI controllers on SPI buses

Currently we have a global spiaddlock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of doing so for the parent controller and hence already holding the global spiaddlock. Since we only care about concurrency within a single SPI bus move the lock to be per controller, avoiding the deadlock.

This can be easily triggered in the case of spi-mux.(CVE-2021-47469)

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

ocfs2: fix race between searching chunks and release journalhead from bufferhead

Encountered a race between ocfs2testbgbitallocatable() and jbd2journalputjournalhead() resulting in the below vmcore.

PID: 106879 TASK: ffff880244ba9c00 CPU: 2 COMMAND: "loop3" Call trace: panic oopsend nocontext _badareanosemaphore badareanosemaphore _dopagefault dopagefault pagefault [exception RIP: ocfs2blockgroupfindclearbits+316] ocfs2blockgroupfindclearbits [ocfs2] ocfs2clustergroupsearch [ocfs2] ocfs2searchchain [ocfs2] ocfs2claimsuballocbits [ocfs2] _ocfs2claimclusters [ocfs2] ocfs2claimclusters [ocfs2] ocfs2localallocslidewindow [ocfs2] ocfs2reservelocalallocbits [ocfs2] ocfs2reserveclusterswithlimit [ocfs2] ocfs2reserveclusters [ocfs2] ocfs2lockrefcountallocators [ocfs2] ocfs2makeclusterswritable [ocfs2] ocfs2replacecow [ocfs2] ocfs2refcountcow [ocfs2] ocfs2filewriteiter [ocfs2] lorwaio loopqueuework kthreadworkerfn kthread retfrom_fork

When ocfs2testbgbitallocatable() called bh2jh(bgbh), the bgbh->bprivate NULL as jbd2journalputjournalhead() raced and released the jounal head from the buffer head. Needed to take bit lock for the bit 'BHJournalHead' to fix this race.(CVE-2021-47493)

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

iio: mma8452: Fix trigger reference couting

The mma8452 driver directly assigns a trigger to the struct iio_dev. The IIO core when done using this trigger will call iio_trigger_put() to drop the reference count by 1.

Without the matching iio_trigger_get() in the driver the reference count can reach 0 too early, the trigger gets freed while still in use and a use-after-free occurs.

Fix this by getting a reference to the trigger before assigning it to the IIO device.(CVE-2021-47500)

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

can: sja1000: fix use after free in emspcmciaadd_card()

If the last channel is not available then "dev" is freed. Fortunately, we can just use "pdev->irq" instead.

Also we should check if at least one channel was set up.(CVE-2021-47521)

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

scsi: mpt3sas: Fix kernel panic during drive powercycle test

While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact.

Consequently, a kernel panic can occur while the driver is trying to access the sasaddress field of sastarget object without also checking the sas_target object for NULL.(CVE-2021-47565)

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

inet_diag: fix kernel-infoleak for UDP sockets

KMSAN reported a kernel-infoleak [1], that can exploited by unpriv users.

After analysis it turned out UDP was not initializing r->idiagexpires. Other users of inetskdiagfill() might make the same mistake in the future, so fix this in inetskdiag_fill().

[1] BUG: KMSAN: kernel-infoleak in instrumentcopytouser include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/ioviter.c:156 [inline] BUG: KMSAN: kernel-infoleak in copytoiter+0x69d/0x25c0 lib/ioviter.c:670 instrumentcopytouser include/linux/instrumented.h:121 [inline] copyout lib/ioviter.c:156 [inline] copytoiter+0x69d/0x25c0 lib/ioviter.c:670 copytoiter include/linux/uio.h:155 [inline] simplecopytoiter+0xf3/0x140 net/core/datagram.c:519 _skbdatagramiter+0x2cb/0x1280 net/core/datagram.c:425 skbcopydatagramiter+0xdc/0x270 net/core/datagram.c:533 skbcopydatagrammsg include/linux/skbuff.h:3657 [inline] netlinkrecvmsg+0x660/0x1c60 net/netlink/afnetlink.c:1974 sockrecvmsgnosec net/socket.c:944 [inline] sockrecvmsg net/socket.c:962 [inline] sockreaditer+0x5a9/0x630 net/socket.c:1035 callreaditer include/linux/fs.h:2156 [inline] newsyncread fs/readwrite.c:400 [inline] vfsread+0x1631/0x1980 fs/readwrite.c:481 ksysread+0x28c/0x520 fs/readwrite.c:619 _dosysread fs/readwrite.c:629 [inline] _sesysread fs/readwrite.c:627 [inline] _x64sysread+0xdb/0x120 fs/readwrite.c:627 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x54/0xd0 arch/x86/entry/common.c:82 entrySYSCALL64afterhwframe+0x44/0xae

Uninit was created at: slabpostallochook mm/slab.h:524 [inline] slaballocnode mm/slub.c:3251 [inline] _kmallocnodetrackcaller+0xe0c/0x1510 mm/slub.c:4974 kmallocreserve net/core/skbuff.c:354 [inline] _allocskb+0x545/0xf90 net/core/skbuff.c:426 allocskb include/linux/skbuff.h:1126 [inline] netlinkdump+0x3d5/0x16a0 net/netlink/afnetlink.c:2245 _netlinkdumpstart+0xd1c/0xee0 net/netlink/afnetlink.c:2370 netlinkdumpstart include/linux/netlink.h:254 [inline] inetdiaghandlercmd+0x2e7/0x400 net/ipv4/inetdiag.c:1343 sockdiagrcvmsg+0x24a/0x620 netlinkrcvskb+0x447/0x800 net/netlink/afnetlink.c:2491 sockdiagrcv+0x63/0x80 net/core/sockdiag.c:276 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0x1095/0x1360 net/netlink/afnetlink.c:1345 netlinksendmsg+0x16f3/0x1870 net/netlink/afnetlink.c:1916 socksendmsgnosec net/socket.c:704 [inline] socksendmsg net/socket.c:724 [inline] sockwriteiter+0x594/0x690 net/socket.c:1057 doiterreadvwritev+0xa7f/0xc70 doiterwrite+0x52c/0x1500 fs/readwrite.c:851 vfswritev fs/readwrite.c:924 [inline] dowritev+0x63f/0xe30 fs/readwrite.c:967 _dosyswritev fs/readwrite.c:1040 [inline] _sesyswritev fs/readwrite.c:1037 [inline] _x64syswritev+0xe5/0x120 fs/readwrite.c:1037 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x54/0xd0 arch/x86/entry/common.c:82 entrySYSCALL64afterhwframe+0x44/0xae

Bytes 68-71 of 312 are uninitialized Memory access of size 312 starts at ffff88812ab54000 Data copied to user address 0000000020001440

CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2021-47597)

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

firmware: arm_scpi: Fix string overflow in SCPI genpd driver

Without the bound checks for scpi_pd->name, it could result in the buffer overflow when copying the SCPI device name from the corresponding device tree node as the name string is set at maximum size of 30.

Let us fix it by using devm_kasprintf so that the string buffer is allocated dynamically.(CVE-2021-47609)

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

ASoC: ops: Reject out of bounds values in sndsocputvolswsx()

We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range.(CVE-2022-48737)

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

powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06

Johan reported the below crash with test_bpf on ppc64 e5500:

testbpf: #296 ALUENDFROMLE 64: 0x0123456789abcdef -> 0x67452301 jited:1 Oops: Exception in kernel mode, sig: 4 [#1] BE PAGESIZE=4K SMP NRCPUS=24 QEMU e500 Modules linked in: testbpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1 NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty) MSR: 0000000080089000 <EE,ME> CR: 88002822 XER: 20000000 IRQMASK: 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .runone+0x104/0x17c [testbpf] Call Trace: .runone+0x60/0x17c [testbpf] (unreliable) .testbpfinit+0x6a8/0xdc8 [testbpf] .dooneinitcall+0x6c/0x28c .doinitmodule+0x68/0x28c .loadmodule+0x2460/0x2abc .dosysinitmodule+0x120/0x18c .systemcallexception+0x110/0x1b8 systemcallcommon+0xf0/0x210 --- interrupt: c00 at 0x101d0acc <...> ---[ end trace 47b2bf19090bb3d0 ]---

Illegal instruction

The illegal instruction turned out to be 'ldbrx' emitted for BPFFROM[L|B]E, which was only introduced in ISA v2.06. Guard use of the same and implement an alternative approach for older processors.(CVE-2022-48755)

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

drm/msm/dsi: invalid parameter check in msmdsiphy_enable

The function performs a check on the "phy" input parameter, however, it is used before the check.

Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference.

Addresses-Coverity-ID: 1493860 ("Null pointer dereference")(CVE-2022-48756)

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

rpmsg: virtio: Free driveroverride when rpmsgremove()

Free driveroverride when rpmsgremove(), otherwise the following memory leak will occur:

unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsgns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] _kmemcacheallocnode+0x1f8/0x320 [<000000002300d89b>] _kmallocnodetrackcaller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driversetoverride+0xd0/0x164 [<000000003e9c4ea5>] rpmsgregisterdeviceoverride+0x98/0x170 [<000000001c0c89a8>] rpmsgnsregisterdevice+0x24/0x30 [<000000008bbf8fa2>] rpmsgprobe+0x2e0/0x3ec [<00000000e65a68df>] virtiodevprobe+0x1c0/0x280 [<00000000443331cc>] reallyprobe+0xbc/0x2dc [<00000000391064b1>] _driverprobedevice+0x78/0xe0 [<00000000a41c9a5b>] driverprobedevice+0xd8/0x160 [<000000009c3bd5df>] _deviceattachdriver+0xb8/0x140 [<0000000043cd7614>] busforeachdrv+0x7c/0xd4 [<000000003b929a36>] _deviceattach+0x9c/0x19c [<00000000a94e0ba8>] deviceinitialprobe+0x14/0x20 [<000000003c999637>] busprobedevice+0xa0/0xac(CVE-2023-52670)

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

Fix page corruption caused by racy check in _freepages

When we upgraded our kernel, we started seeing some page corruption like the following consistently:

BUG: Bad page state in process ganesha.nfsd pfn:1304ca page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca flags: 0x17ffffc0000000() raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000 raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x8664 #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016 Call Trace: dumpstack+0x74/0x96 badpage.cold+0x63/0x94 checknewpagebad+0x6d/0x80 rmqueue+0x46e/0x970 getpagefromfreelist+0xcb/0x3f0 ? _condresched+0x19/0x40 _allocpagesnodemask+0x164/0x300 allocpagescurrent+0x87/0xf0 skbpagefragrefill+0x84/0x110 ...

Sometimes, it would also show up as corruption in the free list pointer and cause crashes.

After bisecting the issue, we found the issue started from commit e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"):

if (put_page_testzero(page))
    free_the_page(page, order);
else if (!PageHead(page))
    while (order-- > 0)
        free_the_page(page + (1 << order), order);

So the problem is the check PageHead is racy because at this point we already dropped our reference to the page. So even if we came in with compound page, the page can already be freed and PageHead can return false and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)

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

atl1c: Work around the DMA RX overflow issue

This is based on alx driver commit 881d0327db37 ("net: alx: Work around the DMA RX overflow issue").

The alx and atl1c drivers had RX overflow error which was why a custom allocator was created to avoid certain addresses. The simpler workaround then created for alx driver, but not for atl1c due to lack of tester.

Instead of using a custom allocator, check the allocated skb address and use skb_reserve() to move away from problematic 0x...fc0 address.

Tested on AR8131 on Acer 4540.(CVE-2023-52834)

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

hid: cp2112: Fix duplicate workqueue initialization

Previously the cp2112 driver called INITDELAYEDWORK within cp2112gpioirqstartup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in setworkdata in workqueue.c, as well as a rare NULL dereference within processone_work in workqueue.c.

Initialize the workqueue within _probe instead.(CVE-2023-52853)

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

ALSA: usb-audio: Stop parsing channels bits when all channels are found.

If a usb audio device sets more bits than the amount of channels it could write outside of the map array.(CVE-2024-27436)

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

media: tc358743: register v4l2 async device only after successful setup

Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access.(CVE-2024-35830)

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

usb: gadget: ffs: Fix race between aiocancel() and AIO request complete

FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following:

DWC3 Gadget                               FFS Application

dwc3gadgetsoftdisconnect() ... --> dwc3stopactivetransfers() --> dwc3gadgetgiveback(-ESHUTDOWN) --> ffsepfileasynciocomplete() ffsaiocancel() --> usbepfreerequest() --> usbep_dequeue()

There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (iodata->req) the FFS application is also referencing it for the usbep_dequeue() call. This can lead to accessing a stale/hanging pointer.

commit b566d38857fc ("usb: gadget: ffs: use iodata->status consistently") relocated the usbepfreerequest() into ffsepfileasynciocomplete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffsepfileasynciocomplete(), as usbep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock.

Fix this issue by moving the usbepfreerequest() back to ffsusercopyworker(), and ensuring that it explicitly sets iodata->req to NULL after freeing it within the ffs->epslock. This resolves the race condition above, as the ffsaiocancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffsusercopy_work() not freeing the USB request until the AIO cancel is done referencing it.

This fix depends on commit b566d38857fc ("usb: gadget: ffs: use iodata->status consistently")(CVE-2024-36894)

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

wifi: nl80211: don't free NULL coalescing rule

If the parsing fails, we can dereference a NULL pointer here.(CVE-2024-36941)

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

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until busresetwork has serviced and cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCIPARAMDEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them.

irqhandler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irqhandler, because we won't service the event until later. irqhandler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irqhandler being called again each time it exits. This freeze can be reproduced by loading firewireohci with "modprobe firewireohci debug=-1" (to enable all debugging output). Apparently there are also some cases where busresetwork will get called soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization.

irqhandler will now leave the event flag set but mask bus reset interrupts, so irqhandler won't be called again and there will be no freeze. If OHCIPARAMDEBUGBUSRESETS is enabled, busreset_work will unmask the interrupt after servicing the event, so future interrupts will be caught as desired.

As a side effect to this change, OHCIPARAMDEBUGBUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after busreset_work has executed.(CVE-2024-36950)

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

net: fix _dstnegative_advice() race

_dstnegativeadvice() does not enforce proper RCU rules when sk->dstcache must be cleared, leading to possible UAF.

RCU rules are that we must first clear sk->skdstcache, then call dstrelease(olddst).

Note that skdstreset(sk) is implementing this protocol correctly, while _dstnegative_advice() uses the wrong order.

Given that ip6negativeadvice() has special logic against RTFCACHE, this means each of the three ->negativeadvice() existing methods must perform the skdstreset() themselves.

Note the check against NULL dst is centralized in _dstnegative_advice(), there is no need to duplicate it in various callbacks.

Many thanks to Clement Lecigne for tracking this issue.

This old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)

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

net: bridge: xmit: make sure we have at least eth header len bytes

syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming.

Tested with dropwatch: drop at: brdevxmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKTTOOSMALL

[1] BUG: KMSAN: uninit-value in brdevxmit+0x61d/0x1cb0 net/bridge/brdevice.c:65 brdevxmit+0x61d/0x1cb0 net/bridge/brdevice.c:65 netdevstartxmit include/linux/netdevice.h:4903 [inline] netdevstartxmit include/linux/netdevice.h:4917 [inline] xmitone net/core/dev.c:3531 [inline] devhardstartxmit+0x247/0xa20 net/core/dev.c:3547 _devqueuexmit+0x34db/0x5350 net/core/dev.c:4341 devqueuexmit include/linux/netdevice.h:3091 [inline] _bpftxskb net/core/filter.c:2136 [inline] _bpfredirectcommon net/core/filter.c:2180 [inline] _bpfredirect+0x14a6/0x1620 net/core/filter.c:2187 _bpfcloneredirect net/core/filter.c:2460 [inline] bpfcloneredirect+0x328/0x470 net/core/filter.c:2432 _bpfprogrun+0x13fe/0xe0f0 kernel/bpf/core.c:1997 _bpfprogrun512+0xb5/0xe0 kernel/bpf/core.c:2238 bpfdispatchernopfunc include/linux/bpf.h:1234 [inline] _bpfprogrun include/linux/filter.h:657 [inline] bpfprogrun include/linux/filter.h:664 [inline] bpftestrun+0x499/0xc30 net/bpf/testrun.c:425 bpfprogtestrunskb+0x14ea/0x1f20 net/bpf/testrun.c:1058 bpfprogtestrun+0x6b7/0xad0 kernel/bpf/syscall.c:4269 _sysbpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 _dosysbpf kernel/bpf/syscall.c:5767 [inline] _sesysbpf kernel/bpf/syscall.c:5765 [inline] _x64sysbpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64syscall+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls64.h:322 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-38538)

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

of: module: add buffer overflow check in of_modalias()

In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).(CVE-2024-38541)

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

drm/amd/display: Fix potential index out of bounds in color transformation function

Fixes index out of bounds issue in the color transformation function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFERFUNCPOINTS).

The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, an error message is logged and the function returns false to indicate an error.

Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10cmcommon.c:405 cmhelpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10cmcommon.c:406 cmhelpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10cmcommon.c:407 cmhelpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.blue' 1025 <= s32max(CVE-2024-38552)

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

ftrace: Fix possible use-after-free issue in ftrace_location()

KASAN reports a bug:

BUG: KASAN: use-after-free in ftracelocation+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dumpstacklvl+0x68/0xa0 printreport+0xcf/0x610 kasanreport+0xb5/0xe0 ftracelocation+0x90/0x120 registerkprobe+0x14b/0xa40 kprobeinit+0x2d/0xff0 [kprobeexample] dooneinitcall+0x8f/0x2d0 doinitmodule+0x13a/0x3c0 loadmodule+0x3082/0x33d0 initmodulefromfile+0xd2/0x130 _x64sysfinitmodule+0x306/0x440 dosyscall64+0x68/0x140 entrySYSCALL64after_hwframe+0x71/0x79

The root cause is that, in lookuprec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftracerelease_mod() as the corresponding module is being deleted:

       CPU1                       |      CPU2

registerkprobes() { | deletemodule() { checkkprobeaddresssafe() { | archcheckftracelocation() { | ftracelocation() { | lookuprec() // USE! | ftracereleasemod() // Free!

To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftracelocationrange(); 2. Use ftracelocationrange() instead of lookuprec() in ftracelocation(); 3. Call synchronizercu() before freeing any ftrace pages both in ftraceprocesslocs()/ftracereleasemod()/ftracefree_mem().(CVE-2024-38588)

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

afunix: Fix data races in unixreleasesock/unixstream_sendmsg

A data-race condition has been identified in afunix. In one data path, the write function unixreleasesock() atomically writes to sk->skshutdown using WRITEONCE. However, on the reader side, unixstream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur:

BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg

write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
unix_release_sock (net/unix/af_unix.c:640)
unix_release (net/unix/af_unix.c:1050)
sock_close (net/socket.c:659 net/socket.c:1421)
__fput (fs/file_table.c:422)
__fput_sync (fs/file_table.c:508)
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
__x64_sys_close (fs/open.c:1541)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
unix_stream_sendmsg (net/unix/af_unix.c:2273)
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
____sys_sendmsg (net/socket.c:2584)
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

value changed: 0x01 -> 0x03

The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").

Commit e1d09c2c2f57 ("afunix: Fix data races around sk->skshutdown.") addressed a comparable issue in the past regarding sk->skshutdown. However, it overlooked resolving this particular data path. This patch only offending unixstreamsendmsg() function, since the other reads seem to be protected by unixstate_lock() as discussed in(CVE-2024-38596)

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

macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"

The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)