OESA-2024-1793

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: ethernet: fix potential use-after-free in ecbhfremove

static void ecbhfremove(struct pcidev *dev) { ... struct ecbhfpriv *priv = netdevpriv(net_dev);

unregister_netdev(net_dev);
free_netdev(net_dev);

pci_iounmap(dev, priv->dma_io);
pci_iounmap(dev, priv->io);

... }

priv is netdev private data, but it is used after freenetdev(). It can cause use-after-free when accessing priv pointer. So, fix it by moving freenetdev() after pci_iounmap() calls.(CVE-2021-47235)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47285)

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

mac80211: track only QoS data frames for admission control

For admission control, obviously all of that only works for QoS data frames, otherwise we cannot even access the QoS field in the header.

Syzbot reported (see below) an uninitialized value here due to a status of a non-QoS nullfunc packet, which isn't even long enough to contain the QoS header.

Fix this to only do anything for QoS data packets.(CVE-2021-47602)

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

scsi: bnx2fc: Make bnx2fcrecvframe() mp safe

Running tests with a debug kernel shows that bnx2fcrecvframe() is modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot a debug kernel and run the bnx2fc driver with the hardware enabled.

[ 1391.699147] BUG: using smpprocessorid() in preemptible [00000000] code: bnx2fc_ [ 1391.699160] caller is bnx2fcrecvframe+0xbf9/0x1760 [bnx2fc] [ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fcl2threa Kdump: loaded Tainted: G B [ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 1391.699183] Call Trace: [ 1391.699188] dumpstacklvl+0x57/0x7d [ 1391.699198] checkpreemptiondisabled+0xc8/0xd0 [ 1391.699205] bnx2fcrecvframe+0xbf9/0x1760 [bnx2fc] [ 1391.699215] ? dorawspintrylock+0xb5/0x180 [ 1391.699221] ? bnx2fcnpivcreatevports.isra.0+0x4e0/0x4e0 [bnx2fc] [ 1391.699229] ? bnx2fcl2rcvthread+0xb7/0x3a0 [bnx2fc] [ 1391.699240] bnx2fcl2rcvthread+0x1af/0x3a0 [bnx2fc] [ 1391.699250] ? bnx2fculpinit+0xc0/0xc0 [bnx2fc] [ 1391.699258] kthread+0x364/0x420 [ 1391.699263] ? rawspinunlockirq+0x24/0x50 [ 1391.699268] ? setkthreadstruct+0x100/0x100 [ 1391.699273] retfromfork+0x22/0x30

Restore the old getcpu/putcpu code with some modifications to reduce the size of the critical section.(CVE-2022-48715)

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

rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev

struct rpmsgctrldev contains a struct cdev. The current code frees the rpmsgctrldev struct in rpmsgctrldevreleasedevice(), but the cdev is a managed object, therefore its release is not predictable and the rpmsgctrldev could be freed before the cdev is entirely released, as in the backtrace below.

[ 93.625603] ODEBUG: free active (active state 0) object type: timerlist hint: delayedworktimerfn+0x0/0x7c [ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debugprintobject+0x13c/0x1b0 [ 93.644799] Modules linked in: veth xtcgroup xtMASQUERADE rfcomm algifhash algifskcipher afalg uinput ip6tablenat fuse uvcvideo videobuf2vmalloc venusenc venusdec videobuf2dmacontig hciuart btandroid btqca sndsocrt5682i2c bluetooth qcomspmitempalarm sndsocrt5682v [ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26 [ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT) [ 93.730055] Workqueue: events kobjectdelayedcleanup [ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO) [ 93.740216] pc : debugprintobject+0x13c/0x1b0 [ 93.744890] lr : debugprintobject+0x13c/0x1b0 [ 93.749555] sp : ffffffacf5bc7940 [ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000 [ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000 [ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000 [ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0 [ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0 [ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0 [ 93.785814] x17: 0000000000000000 x16: dfffffd000000000 [ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c [ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000 [ 93.802244] x11: 0000000000000001 x10: 0000000000000000 [ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900 [ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000 [ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000 [ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001 [ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061 [ 93.835104] Call trace: [ 93.837644] debugprintobject+0x13c/0x1b0 [ 93.841963] _debugchecknoobjfreed+0x25c/0x3c0 [ 93.846987] debugchecknoobjfreed+0x18/0x20 [ 93.851669] slabfreefreelisthook+0xbc/0x1e4 [ 93.856346] kfree+0xfc/0x2f4 [ 93.859416] rpmsgctrldevreleasedevice+0x78/0xb8 [ 93.864445] devicerelease+0x84/0x168 [ 93.868310] kobjectcleanup+0x12c/0x298 [ 93.872356] kobjectdelayedcleanup+0x10/0x18 [ 93.876948] processonework+0x578/0x92c [ 93.881086] workerthread+0x804/0xcf8 [ 93.884963] kthread+0x2a8/0x314 [ 93.888303] retfromfork+0x10/0x18

The cdevdeviceadd/del() API was created to address this issue (see commit '233ed09d7fda ("chardev: add helper function to register char devs with a struct device")'), use it instead of cdev add/del().(CVE-2022-48759)

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

phonet: fix rtmphonetnotify() skb allocation

fill_route() stores three components in the skb:

• struct rtmsg
• RTA_DST (u8)
• RTA_OIF (u32)

Therefore, rtmphonetnotify() should use

NLMSGALIGN(sizeof(struct rtmsg)) + nlatotalsize(1) + nlatotal_size(4)(CVE-2024-36946)

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

virtio: delete vq in vpfindvqsmsix() when requestirq() fails

When requestirq() fails, error path calls vpdelvqs(). There, as vq is present in the list, freeirq() is called for the same vector. That causes following splat:

[ 0.414355] Trying to free already-free IRQ 27 [ 0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 freeirq+0x1a1/0x2d0 [ 0.414510] Modules linked in: [ 0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27 [ 0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 [ 0.414540] RIP: 0010:freeirq+0x1a1/0x2d0 [ 0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 <0f> 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40 [ 0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086 [ 0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000 [ 0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001 [ 0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001 [ 0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760 [ 0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600 [ 0.414540] FS: 0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000 [ 0.414540] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0 [ 0.414540] Call Trace: [ 0.414540] <TASK> [ 0.414540] ? warn+0x80/0x120 [ 0.414540] ? freeirq+0x1a1/0x2d0 [ 0.414540] ? reportbug+0x164/0x190 [ 0.414540] ? handlebug+0x3b/0x70 [ 0.414540] ? excinvalidop+0x17/0x70 [ 0.414540] ? asmexcinvalidop+0x1a/0x20 [ 0.414540] ? freeirq+0x1a1/0x2d0 [ 0.414540] vpdelvqs+0xc1/0x220 [ 0.414540] vpfindvqsmsix+0x305/0x470 [ 0.414540] vpfindvqs+0x3e/0x1a0 [ 0.414540] vpmodernfindvqs+0x1b/0x70 [ 0.414540] initvqs+0x387/0x600 [ 0.414540] virtnetprobe+0x50a/0xc80 [ 0.414540] virtiodevprobe+0x1e0/0x2b0 [ 0.414540] reallyprobe+0xc0/0x2c0 [ 0.414540] ? _pfxdriverattach+0x10/0x10 [ 0.414540] _driverprobedevice+0x73/0x120 [ 0.414540] driverprobedevice+0x1f/0xe0 [ 0.414540] _driverattach+0x88/0x180 [ 0.414540] busforeachdev+0x85/0xd0 [ 0.414540] busadddriver+0xec/0x1f0 [ 0.414540] driverregister+0x59/0x100 [ 0.414540] ? _pfxvirtionetdriverinit+0x10/0x10 [ 0.414540] virtionetdriverinit+0x90/0xb0 [ 0.414540] dooneinitcall+0x58/0x230 [ 0.414540] kernelinitfreeable+0x1a3/0x2d0 [ 0.414540] ? _pfxkernelinit+0x10/0x10 [ 0.414540] kernelinit+0x1a/0x1c0 [ 0.414540] retfromfork+0x31/0x50 [ 0.414540] ? _pfxkernelinit+0x10/0x10 [ 0.414540] retfromforkasm+0x1a/0x30 [ 0.414540] </TASK>

Fix this by calling deleting the current vq when request_irq() fails.(CVE-2024-37353)

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

drm/mediatek: Add 0 size check to mtkdrmgem_obj

Add a check to mtkdrmgem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer.

Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL.(CVE-2024-38549)

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

scsi: bfa: Ensure the copied buf is NUL terminated

Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdupusernul instead of memdup_user.(CVE-2024-38560)

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

speakup: Fix sizeof() vs ARRAY_SIZE() bug

The "buf" pointer is an array of u16 values. This code should be using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512), otherwise it can the still got out of bounds.(CVE-2024-38587)

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

jffs2: prevent xattr node from overflowing the eraseblock

Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker.

Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as:

jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) doverifyxattrdatum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2getinodenodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2scaneraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead

This breaks the filesystem and can lead to KASAN crashes such as:

BUG: KASAN: slab-out-of-bounds in jffs2sumaddkvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: <TASK> dumpstacklvl+0xc6/0x120 printreport+0xc4/0x620 ? _virtaddrvalid+0x308/0x5b0 kasanreport+0xc1/0xf0 ? jffs2sumaddkvec+0x125e/0x15d0 ? jffs2sumaddkvec+0x125e/0x15d0 jffs2sumaddkvec+0x125e/0x15d0 jffs2flashdirectwritev+0xa8/0xd0 jffs2flashwritev+0x9c9/0xef0 ? _x64syssetxattr+0xc4/0x160 ? dosyscall64+0x69/0x140 ? entrySYSCALL64after_hwframe+0x76/0x7e [...]

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)

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

ring-buffer: Fix a race between readers and resize checks

The reader code in rbgetreader_page() swaps a new reader page into the ring buffer by doing cmpxchg on old->list.prev->next to point it to the new page. Following that, if the operation is successful, old->list.next->prev gets updated too. This means the underlying doubly-linked list is temporarily inconsistent, page->prev->next or page->next->prev might not be equal back to page for some page in the ring buffer.

The resize operation in ringbufferresize() can be invoked in parallel. It calls rbcheckpages() which can detect the described inconsistency and stop further tracing:

[ 190.271762] ------------[ cut here ]------------ [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ringbuffer.c:1467 rbcheckpages.isra.0+0x6a/0xa0 [ 190.271789] Modules linked in: [...] [ 190.271991] Unloaded tainted modules: inteluncorefrequency(E):1 skxedac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014 [ 190.272015] RIP: 0010:rbcheckpages.isra.0+0x6a/0xa0 [ 190.272023] Code: [...] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80 [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 190.272077] Call Trace: [ 190.272098] <TASK> [ 190.272189] ringbufferresize+0x2ab/0x460 [ 190.272199] _tracingresizeringbuffer.part.0+0x23/0xa0 [ 190.272206] tracingresizeringbuffer+0x65/0x90 [ 190.272216] tracingentrieswrite+0x74/0xc0 [ 190.272225] vfswrite+0xf5/0x420 [ 190.272248] ksyswrite+0x67/0xe0 [ 190.272256] dosyscall64+0x82/0x170 [ 190.272363] entrySYSCALL64afterhwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d263 [ 190.272381] Code: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIGRAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002 [ 190.272412] </TASK> [ 190.272414] ---[ end trace 0000000000000000 ]---

Note that ringbufferresize() calls rbcheckpages() only if the parent trace_buffer has recording disabled. Recent commit d78ab792705c ("tracing: Stop current tracer when resizing buffer") causes that it is now always the case which makes it more likely to experience this issue.

The window to hit this race is nonetheless very small. To help reproducing it, one can add a delay loop in rbgetreader_page():

ret = rbheadpagereplace(reader, cpubuffer->readerpage); if (!ret) goto spin; for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */ asm volatile ("" : : : "memory"); rblisthead(reader->list.next)->prev = &cpubuffer->reader_page->list;

.. ---truncated---(CVE-2024-38601)

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

m68k: Fix spinlock race in kernel thread creation

Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch.

This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register.

The situation is different for newly created kernel threads. The status register is set to PSS in copythread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switchto() aka resume(), interrupts then become enabled prematurely. resume() then returns via retfromkernelthread() and scheduletail() where run queue lock is released (see finishtaskswitch() and finishlock_switch()).

A timer interrupt calling schedulertick() before the lock is released in finishtask_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck.

As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split retfromfork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit.

Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). Disable interrupts temporarily when switching the tasks' register sets in resume().

Note that a simple oriw 0x700,%sr after restoring sr is not enough here - this leaves enough of a race for the 'spinlock recursion' warning to still be observed.

Tested on ARAnyM and qemu (Quadra 800 emulation).(CVE-2024-38613)

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

media: stk1160: fix bounds checking in stk1160copyvideo()

The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true.

Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". Instead, the math to calculate the destination where we are writing is a bit involved. You calculate the number of full lines already written, multiply by two, skip a line if necessary so that we start on an odd numbered line, and add the offset into the line.

To fix this buffer overflow, just take the actual destination where we are writing, if the offset is already out of bounds print an error and return. Otherwise, write up to buf->length bytes.(CVE-2024-38621)

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

watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger

When the cpu5wdt module is removing, the origin code uses deltimer() to de-activate the timer. If the timer handler is running, deltimer() could not stop it and will return directly. If the port region is released by releaseregion() and then the timer handler cpu5wdttrigger() calls outb() to write into the region that is released, the use-after-free bug will happen.

Change deltimer() to timershutdown_sync() in order that the timer handler could be finished before the port region is released.(CVE-2024-38630)

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

s390/ap: Fix crash in AP internal function modify_bitmap()

A system crash like this

Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (apparsebitmapstr+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] apparsebitmapstr+0x10e/0x1f8 ([<0000014b75e7b5dc>] apparsebitmapstr+0xe4/0x1f8) [<0000014b75e7b758>] apmaskstore+0x68/0x140 [<0000014b75679196>] kernfsfopwriteiter+0x14e/0x1e8 [<0000014b75598524>] vfswrite+0x1b4/0x448 [<0000014b7559894c>] ksyswrite+0x74/0x100 [<0000014b7618a440>] _dosyscall+0x268/0x328 [<0000014b761a3558>] systemcall+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] apparsebitmapstr+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: paniconoops

occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.

The fix is simple: use unsigned long values for the internal variables. The correct checks are already in place in the function but a simple int for the internal variables was used with the possibility to overflow.(CVE-2024-38661)

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

um: Add winch to winch_handlers before registering winch IRQ

Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list.

If that happens, registerwinchirq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup().

Avoid the race by adding the winch to the winchhandlers list before registering the IRQ, and rolling back if umrequest_irq() fails.(CVE-2024-39292)