OESA-2024-2122

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ibmvnic: free reset-work-item when flushing

Fix a tiny memory leak when flushing the reset work queue.(CVE-2022-48905)

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

xen/netfront: destroy queues before realnumtx_queues is zeroed

xennetdestroyqueues() relies on info->netdev->realnumtxqueues to delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 ("net-sysfs: update the queue counts in the unregistration path"), unregisternetdev() indirectly sets realnumtxqueues to 0. Those two facts together means, that xennetdestroyqueues() called from xennetremove() cannot do its job, because it's called after unregister_netdev(). This results in kfree-ing queues that are still linked in napi, which ultimately crashes:

BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 52 Comm: xenwatch Tainted: G        W         5.16.10-1.32.fc32.qubes.x86_64+ #226
RIP: 0010:free_netdev+0xa3/0x1a0
Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00
RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff
RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050
R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680
FS:  0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0
Call Trace:
 <TASK>
 xennet_remove+0x13d/0x300 [xen_netfront]
 xenbus_dev_remove+0x6d/0xf0
 __device_release_driver+0x17a/0x240
 device_release_driver+0x24/0x30
 bus_remove_device+0xd8/0x140
 device_del+0x18b/0x410
 ? _raw_spin_unlock+0x16/0x30
 ? klist_iter_exit+0x14/0x20
 ? xenbus_dev_request_and_reply+0x80/0x80
 device_unregister+0x13/0x60
 xenbus_dev_changed+0x18e/0x1f0
 xenwatch_thread+0xc0/0x1a0
 ? do_wait_intr_irq+0xa0/0xa0
 kthread+0x16b/0x190
 ? set_kthread_struct+0x40/0x40
 ret_from_fork+0x22/0x30
 </TASK>

Fix this by calling xennetdestroyqueues() from xennetuninit(), when realnumtxqueues is still available. This ensures that queues are destroyed when realnumtxqueues is set to 0, regardless of how unregisternetdev() was called.

Originally reported at https://github.com/QubesOS/qubes-issues/issues/7257(CVE-2022-48914)

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

usb: gadget: rndis: add spinlock for rndis response list

There's no lock for rndis response list. It could cause list corruption if there're two different listadd at the same time like below. It's better to add in rndisaddresponse / rndisfreeresponse / rndisgetnextresponse to prevent any race condition on response list.

[ 361.894299] [1: irq/191-dwc3:16979] list_add corruption. next->prev should be prev (ffffff80651764d0), but was ffffff883dc36f80. (next=ffffff80651764d0).

[ 361.904380] [1: irq/191-dwc3:16979] Call trace: [ 361.904391] [1: irq/191-dwc3:16979] _listaddvalid+0x74/0x90 [ 361.904401] [1: irq/191-dwc3:16979] rndismsgparser+0x168/0x8c0 [ 361.904409] [1: irq/191-dwc3:16979] rndiscommandcomplete+0x24/0x84 [ 361.904417] [1: irq/191-dwc3:16979] usbgadgetgivebackrequest+0x20/0xe4 [ 361.904426] [1: irq/191-dwc3:16979] dwc3gadgetgiveback+0x44/0x60 [ 361.904434] [1: irq/191-dwc3:16979] dwc3ep0completedata+0x1e8/0x3a0 [ 361.904442] [1: irq/191-dwc3:16979] dwc3ep0interrupt+0x29c/0x3dc [ 361.904450] [1: irq/191-dwc3:16979] dwc3processevententry+0x78/0x6cc [ 361.904457] [1: irq/191-dwc3:16979] dwc3processeventbuf+0xa0/0x1ec [ 361.904465] [1: irq/191-dwc3:16979] dwc3thread_interrupt+0x34/0x5c(CVE-2022-48926)

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

powerpc/pseries/memhp: Fix access beyond end of drmem array

dlparmemoryremovebyindex() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmeminfo->lmbs[drmeminfo->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer:

    pr_debug("Failed to hot-remove memory at %llx\n",
             lmb->base_addr);

This was found by inspection and confirmed with KASAN:

pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949

dumpstacklvl+0xa4/0xfc (unreliable) printreport+0x214/0x63c kasanreport+0x140/0x2e0 _asanload8+0xa8/0xe0 dlparmemory+0x298/0x1658 handledlparerrorlog+0x130/0x1d0 dlparstore+0x18c/0x3e0 kobjattrstore+0x68/0xa0 sysfskfwrite+0xc4/0x110 kernfsfopwriteiter+0x26c/0x390 vfswrite+0x2d4/0x4e0 ksyswrite+0xac/0x1a0 systemcallexception+0x268/0x530 systemcallvectoredcommon+0x15c/0x2ec

Allocated by task 1: kasansavestack+0x48/0x80 kasansettrack+0x34/0x50 kasansaveallocinfo+0x34/0x50 _kasankmalloc+0xd0/0x120 _kmalloc+0x8c/0x320 kmallocarray.constprop.0+0x48/0x5c drmeminit+0x2a0/0x41c dooneinitcall+0xe0/0x5c0 kernelinitfreeable+0x4ec/0x5a0 kernelinit+0x30/0x1e0 retfromkerneluser_thread+0x14/0x1c

The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0)

================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0

Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry.(CVE-2023-52451)

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

crypto: scomp - fix req->dst buffer overflow

The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem.(CVE-2023-52612)

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

usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency

In dwc2hcdurbenqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In dwc2hcdurbdequeue():

spin_lock_irqsave(&hsotg->lock, flags);
...
if (!urb->hcpriv) {
    dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
    goto out;
}
rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
...

out: spinunlockirqrestore(&hsotg->lock, flags);

When dwc2hcdurbenqueue() and dwc2hcdurbdequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2hcdurb_dequeue(), which can cause a NULL pointer dereference.

This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5.

To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic.(CVE-2023-52855)

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

usb: gadget: fncm: fix potential NULL ptr deref in ncmbitrate()

In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device.

AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10

The call stack is: ncmclose() -> ncmnotify() -> ncmdonotify() with the crash at: ncmdonotify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)

Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):

// halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usbcdcnotification) 0B 0D 00 79 strh w11, [x8, #6]

// word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8]

// x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usbcompositedev 2A 01 40 F9 ldr x10, [x9]

// loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19]

// x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]

which seems to line up with ncmdonotify() case NCMNOTIFYSPEED code fragment:

event->wLength = cputole16(8); req->length = NCMSTATUSBYTECOUNT;

/* SPEEDCHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cputole32(ncmbitrate(cdev->gadget));

My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cputole32(ncmbitrate(cdev->gadget)); which calls: ncmbitrate(NULL) which then calls: gadgetissuperspeed(NULL) which reads ((struct usbgadget *)NULL)->maxspeed and hits a panic.

AFAICT, if I'm counting right, the offset of maxspeed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct workstruct)

It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing...(CVE-2023-52894)

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

nfc: pn533: Wait for outurb's completion in pn533usbsendframe()

Fix a use-after-free that occurs in hcd when inurb sent from pn533usbsendframe() is completed earlier than outurb. Its callback frees the skb data in pn533sendasynccomplete() that is used as a transfer buffer of outurb. Wait before sending inurb until the callback of outurb is called. To modify the callback of outurb alone, separate the complete function of outurb and ackurb.

Found by a modified version of syzkaller.

BUG: KASAN: use-after-free in dummytimer Call Trace: memcpy (mm/kasan/shadow.c:65) dummyperformtransfer (drivers/usb/gadget/udc/dummyhcd.c:1352) transfer (drivers/usb/gadget/udc/dummyhcd.c:1453) dummytimer (drivers/usb/gadget/udc/dummyhcd.c:1972) archstaticbranch (arch/x86/include/asm/jumplabel.h:27) statickeyfalse (include/linux/jumplabel.h:207) timerexpireexit (include/trace/events/timer.h:127) calltimerfn (kernel/time/timer.c:1475) expiretimers (kernel/time/timer.c:1519) _runtimers (kernel/time/timer.c:1790) runtimersoftirq (kernel/time/timer.c:1803)(CVE-2023-52907)

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

drm/i915/gem: Fix Virtual Memory mapping boundaries calculation

Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access.

Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses.

Additionally, the calculations have been rewritten in a clearer and more understandable form.

[Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)

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

nilfs2: handle inconsistent state in nilfsbtnodecreate_block()

Syzbot reported that a buffer state inconsistency was detected in nilfsbtnodecreate_block(), triggering a kernel bug.

It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state.

So, modify nilfsbtnodecreate_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)

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

dev/parport: fix the array out-of-bounds risk

Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed.

Below is the stack trace I encountered during the actual issue:

[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: dohardwarebaseaddr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dumpbacktrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] showstack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dumpstack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] _stackchkfail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] dohardwarebaseaddr+0xcc/0xd0 parport

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

dma: fix call order in dmamfreecoherent

dmamfreecoherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list.

If this happens, there will be two entries in the devres list with the same vaddr and devresdestroy() can free the wrong entry, triggering the WARNON() in dmam_match.

Fix by destroying the devres entry before freeing the DMA allocation.

kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03(CVE-2024-43856)

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

jfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)

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

devres: Fix memory leakage caused by driver API devmfreepercpu()

It will cause memory leakage when use driver API devmfreepercpu() to free memory allocated by devmallocpercpu(), fixed by using devresrelease() instead of devresdestroy() within devmfreepercpu().(CVE-2024-43871)

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

md/raid5: avoid BUG_ON() while continue reshape after reassembling

Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUG_ON() can be triggerred by the test:

kernel BUG at drivers/md/raid5.c:6278! invalid opcode: 0000 [#1] PREEMPT SMP PTI irq event stamp: 158985 CPU: 6 PID: 891 Comm: md0reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshaperequest+0x3f1/0xe60 Call Trace: <TASK> raid5syncrequest+0x43d/0x550 mddosync+0xb7a/0x2110 mdthread+0x294/0x2b0 kthread+0x147/0x1c0 retfromfork+0x59/0x70 retfromforkasm+0x1a/0x30 </TASK>

Root cause is that --revert-reshape update the raid_disks from 5 to 4, while reshape position is still set, and after reassembling the array, reshape position will be read from super block, then during reshape the checking of 'writepos' that is caculated by old reshape position will fail.

Fix this panic the easy way first, by converting the BUGON() to WARNON(), and stop the reshape if checkings fail.

Noted that mdadm must fix --revert-shape as well, and probably md/raid should enhance metadata validation as well, however this means reassemble will fail and there must be user tools to fix the wrong metadata.(CVE-2024-43914)