OESA-2024-1792

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs

It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadgetgiveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by uether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped.

Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3gadgetgiveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncmunwrapntb: K: ncmunwrapntb toprocess: 1025 [002] d..1 7828.532867: ncmunwrapntb: K: ncmunwrapntb nth: 1751999342 [002] d..1 7828.532868: ncmunwrapntb: K: ncmunwrapntb seq: 0xce67 [002] d..1 7828.532868: ncmunwrapntb: K: ncmunwrapntb blklen: 0x400 [002] d..1 7828.532868: ncmunwrapntb: K: ncmunwrapntb ndplen: 0x10 [002] d..1 7828.532869: ncmunwrapntb: K: Parsed NTB with 1 frames

In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list.

Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3gadgetgiveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncmunwrapntb: K: ncmunwrapntb nth: 1751999342 [002] d..1 7828.557950: ncmunwrapntb: K: ncmunwrapntb blk_len: 0x800

Lecroy shows one byte coming in extra confirming that the byte is coming in from PC:

Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)

According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize.(CVE-2024-27405)

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

ipv6: fix potential "struct net" leak in inet6rtmgetaddr()

It seems that if userspace provides a correct IFATARGETNETNSID value but no IFAADDRESS and IFALOCAL attributes, inet6rtmgetaddr() returns -EINVAL with an elevated "struct net" refcount.(CVE-2024-27417)

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

netfilter: nftables: flush pending destroy work before exitnet release

Similar to 2c9f0293280e ("netfilter: nftables: flush pending destroy work before netlink notifier") to address a race between exitnet and the destroy workqueue.

The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction.

[ 1360.547789] BUG: KASAN: slab-use-after-free in nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nftablestransdestroywork [nftables] [ 1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dumpstacklvl+0x53/0x70 [ 1360.548014] printreport+0xc4/0x610 [ 1360.548026] ? virtaddrvalid+0xba/0x160 [ 1360.548040] ? _pfxrawspinlockirqsave+0x10/0x10 [ 1360.548054] ? nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.548176] kasanreport+0xae/0xe0 [ 1360.548189] ? nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.548312] nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.548447] ? _pfxnftablestransdestroywork+0x10/0x10 [nftables] [ 1360.548577] ? rawspinunlockirq+0x18/0x30 [ 1360.548591] processonework+0x2f1/0x670 [ 1360.548610] workerthread+0x4d3/0x760 [ 1360.548627] ? _pfxworkerthread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? _pfxkthread+0x10/0x10 [ 1360.548665] retfromfork+0x2f/0x50 [ 1360.548679] ? _pfxkthread+0x10/0x10 [ 1360.548690] retfromfork_asm+0x1a/0x30 [ 1360.548707] </TASK>

[ 1360.548719] Allocated by task 192061: [ 1360.548726] kasansavestack+0x20/0x40 [ 1360.548739] kasansavetrack+0x14/0x30 [ 1360.548750] kasankmalloc+0x8f/0xa0 [ 1360.548760] _kmallocnode+0x1f1/0x450 [ 1360.548771] nftablesnewset+0x10c7/0x1b50 [nftables] [ 1360.548883] nfnetlinkrcvbatch+0xbc4/0xdc0 [nfnetlink] [ 1360.548909] nfnetlinkrcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlinkunicast+0x367/0x4f0 [ 1360.548935] netlinksendmsg+0x34b/0x610 [ 1360.548944] _syssendmsg+0x4d4/0x510 [ 1360.548953] _syssendmsg+0xc9/0x120 [ 1360.548961] _syssendmsg+0xbe/0x140 [ 1360.548971] dosyscall64+0x55/0x120 [ 1360.548982] entrySYSCALL64afterhwframe+0x55/0x5d

[ 1360.548994] Freed by task 192222: [ 1360.548999] kasansavestack+0x20/0x40 [ 1360.549009] kasansavetrack+0x14/0x30 [ 1360.549019] kasansavefreeinfo+0x3b/0x60 [ 1360.549028] poisonslabobject+0x100/0x180 [ 1360.549036] _kasanslabfree+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] _nftreleasetable+0x473/0x6a0 [nftables] [ 1360.549131] nftablesexitnet+0x170/0x240 [nftables] [ 1360.549221] opsexitlist+0x50/0xa0 [ 1360.549229] freeexitlist+0x101/0x140 [ 1360.549236] unregisterpernetoperations+0x107/0x160 [ 1360.549245] unregisterpernetsubsys+0x1c/0x30 [ 1360.549254] nftablesmoduleexit+0x43/0x80 [nftables] [ 1360.549345] _dosysdeletemodule+0x253/0x370 [ 1360.549352] dosyscall64+0x55/0x120 [ 1360.549360] entrySYSCALL64afterhwframe+0x55/0x5d

(gdb) list *_nftreleasetable+0x473 0x1e033 is in _nftreleasetable (net/netfilter/nftablesapi.c:11354). 11349 listforeachentrysafe(flowtable, nf, &table->flowtables, list) { 11350 listdel(&flowtable->list); 11351 nftusedec(&table->use); 11352 nftablesflowtabledestroy(flowtable); 11353 } 11354 listforeachentrysafe(set, ns, &table->sets, list) { 11355 listdel(&set->list); 11356 nftusedec(&table->use); 11357 if (set->flags & (NFTSETMAP | NFTSETOBJECT)) 11358 nftmap_deactivat ---truncated---(CVE-2024-35899)

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

dyndbg: fix old BUG_ON in >control parser

Fix a BUGON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing prerr and return -EINVAL instead.(CVE-2024-35947)

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

net/sched: taprio: always validate TCATAPRIOATTR_PRIOMAP

If one TCATAPRIOATTRPRIOMAP attribute has been provided, taprioparsemqprioopt() must validate it, or userspace can inject arbitrary data to the kernel, the second time taprio_change() is called.

First call (with valid attributes) sets dev->num_tc to a non zero value.

Second call (with arbitrary mqprio attributes) returns early from taprioparsemqprio_opt() and bad things can happen.(CVE-2024-36974)

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

tcp: Fix shift-out-of-bounds in dctcpupdatealpha().

In dctcpupdatealpha(), we use a module parameter dctcpshiftg as follows:

alpha -= minnotzero(alpha, alpha >> dctcpshiftg); ... deliveredce <<= (10 - dctcpshift_g);

It seems syzkaller started fuzzing module parameters and triggered shift-out-of-bounds [0] by setting 100 to dctcpshiftg:

memcpy((void)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47); res = syscall(NR_openat, /fd=/0xffffffffffffff9cul, /file=/0x20000080ul, /flags=/2ul, /mode=/0ul); memcpy((void)0x20000000, "100\000", 4); syscall(NR_write, /fd=/r[0], /val=/0x20000000ul, /len=/4ul);

Let's limit the max value of dctcpshiftg by paramsetuint_minmax().

With this patch:

# echo 10 > /sys/module/tcpdctcp/parameters/dctcpshiftg # cat /sys/module/tcpdctcp/parameters/dctcpshiftg 10 # echo 11 > /sys/module/tcpdctcp/parameters/dctcpshift_g -bash: echo: write error: Invalid argument

shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x201/0x300 lib/dumpstack.c:114 ubsanepilogue lib/ubsan.c:231 [inline] _ubsanhandleshiftoutofbounds+0x346/0x3a0 lib/ubsan.c:468 dctcpupdatealpha+0x540/0x570 net/ipv4/tcpdctcp.c:143 tcpinackevent net/ipv4/tcpinput.c:3802 [inline] tcpack+0x17b1/0x3bc0 net/ipv4/tcpinput.c:3948 tcprcvstateprocess+0x57a/0x2290 net/ipv4/tcpinput.c:6711 tcpv4dorcv+0x764/0xc40 net/ipv4/tcpipv4.c:1937 skbacklogrcv include/net/sock.h:1106 [inline] _releasesock+0x20f/0x350 net/core/sock.c:2983 releasesock+0x61/0x1f0 net/core/sock.c:3549 mptcpsubflowshutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcpchecksenddatafin+0x225/0x410 net/mptcp/protocol.c:2976 _mptcpclose+0x238/0xad0 net/mptcp/protocol.c:3072 mptcpclose+0x2a/0x1a0 net/mptcp/protocol.c:3127 inetrelease+0x190/0x1f0 net/ipv4/afinet.c:437 _sockrelease net/socket.c:659 [inline] sockclose+0xc0/0x240 net/socket.c:1421 _fput+0x41b/0x890 fs/filetable.c:422 taskworkrun+0x23b/0x300 kernel/taskwork.c:180 exittaskwork include/linux/taskwork.h:38 [inline] doexit+0x9c8/0x2540 kernel/exit.c:878 dogroupexit+0x201/0x2b0 kernel/exit.c:1027 _dosysexitgroup kernel/exit.c:1038 [inline] _sesysexitgroup kernel/exit.c:1036 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1036 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xe4/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Code: Unable to access opcode bytes at 0x7f6c2b50058c. RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>(CVE-2024-37356)

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/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:

net: fec: remove .ndopollcontroller to avoid deadlocks

There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndopollcontroller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disableirq() is called by .ndopollcontroller interface of sungem driver, however, disableirq() might sleep. After analyzing the implementation of fecpollcontroller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndopollcontroller is unnecessary to be implemented in the fec driver, so fecpollcontroller() can be safely removed.(CVE-2024-38553)

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

net/mlx5: Discard command completions in internal error

Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually.

Kernel log: ------------[ cut here ]------------ refcountt: underflow; use-after-free. ... RIP: 0010:refcountwarnsaturate+0xd8/0xe0 ... Call Trace: <IRQ> ? _warn+0x79/0x120 ? refcountwarnsaturate+0xd8/0xe0 ? reportbug+0x17c/0x190 ? handlebug+0x3c/0x60 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? refcountwarnsaturate+0xd8/0xe0 cmdentput+0x13b/0x160 [mlx5core] mlx5cmdcomphandler+0x5f9/0x670 [mlx5core] cmdcompnotifier+0x1f/0x30 [mlx5core] notifiercallchain+0x35/0xb0 atomicnotifiercallchain+0x16/0x20 mlx5eqasyncint+0xf6/0x290 [mlx5core] notifiercallchain+0x35/0xb0 atomicnotifiercallchain+0x16/0x20 irqinthandler+0x19/0x30 [mlx5core] _handleirqeventpercpu+0x4b/0x160 handleirqevent+0x2e/0x80 handleedgeirq+0x98/0x230 _commoninterrupt+0x3b/0xa0 commoninterrupt+0x7b/0xa0 </IRQ> <TASK> asmcommon_interrupt+0x22/0x40(CVE-2024-38555)

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

net/mlx5: Add a timeout to acquire the command queue semaphore

Prevent forced completion handling on an entry that has not yet been assigned an index, causing an out of bounds access on idx = -22. Instead of waiting indefinitely for the sem, blocking flow now waits for index to be allocated or a sem acquisition timeout before beginning the timer for FW completion.

Kernel log example: mlx5core 0000:06:00.0: waitfunchandleexectimeout:1128:(pid 185911): cmd[-22]: CREATEUCTX(0xa04) No done completion(CVE-2024-38556)

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

bpf: Add BPFPROGTYPECGROUPSKB attach type enforcement in BPFLINKCREATE

bpfprogattach uses attachtypetoprogtype to enforce proper attach type for BPFPROGTYPECGROUPSKB. linkcreate uses bpfprogget and relies on bpfprogattachcheckattachtype to properly verify progtype <> attachtype association.

Add missing attachtype enforcement for the linkcreate case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks.(CVE-2024-38564)

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:

fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow

For example, in the expression: vbo = 2 * vbo + skip(CVE-2024-38624)

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)