OESA-2024-2518

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

serial: sc16is7xx: fix invalid FIFO access with special register set

When enabling access to the special register set, Receiver time-out and RHR interrupts can happen. In this case, the IRQ handler will try to read from the FIFO thru the RHR register at address 0x00, but address 0x00 is mapped to DLL register, resulting in erroneous FIFO reading.

Call graph example: sc16is7xxstartup(): entry sc16is7xxmsproc(): entry sc16is7xxsettermios(): entry sc16is7xxsetbaud(): DLH/DLL = $009C --> access special register set sc16is7xxportirq() entry --> IIR is 0x0C sc16is7xxhandlerx() entry sc16is7xxfiforead(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCRCONFMODEA) sc16is7xxsetbaud(): exit --> Restore access to general register set

Fix the problem by claiming the efr_lock mutex when accessing the Special register set.(CVE-2024-44950)

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

drm/amd/display: Check link_index before accessing dc->links[]

[WHY & HOW] dc->links[] has max size of MAX_LINKS and NULL is return when trying to access with out-of-bound index.

This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.(CVE-2024-46813)

In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6uncachedlistflushdev() Blamed commit accidentally removed a check for rt->rt6iidev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6uncachedlistflushdev net/ipv6/route.c:177 [inline] RIP: 0010:rt6disableip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> addrconfifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconfnotify+0x3cb/0x1020 notifiercallchain+0x19f/0x3e0 kernel/notifier.c:93 callnetdevicenotifiersextack net/core/dev.c:2032 [inline] callnetdevicenotifiers net/core/dev.c:2046 [inline] unregisternetdevicemanynotify+0xd81/0x1c40 net/core/dev.c:11352 unregisternetdevicemany net/core/dev.c:11414 [inline] unregisternetdevicequeue+0x303/0x370 net/core/dev.c:11289 unregisternetdevice include/linux/netdevice.h:3129 [inline] _tundetach+0x6b9/0x1600 drivers/net/tun.c:685 tundetach drivers/net/tun.c:701 [inline] tunchrclose+0x108/0x1b0 drivers/net/tun.c:3510 _fput+0x24a/0x8a0 fs/filetable.c:422 taskworkrun+0x24f/0x310 kernel/taskwork.c:228 exittaskwork include/linux/taskwork.h:40 [inline] doexit+0xa2f/0x27f0 kernel/exit.c:882 dogroupexit+0x207/0x2c0 kernel/exit.c:1031 _dosysexitgroup kernel/exit.c:1042 [inline] _sesysexitgroup kernel/exit.c:1040 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1040 x64syscall+0x2634/0x2640 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6uncachedlistflushdev net/ipv6/route.c:177 [inline] RIP: 0010:rt6disableip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---(CVE-2024-47707)

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtwwaitfirmwarecompletion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtwusbintfinit()' has failed in 'rtwusbprobe()', 'rtwusbdisconnect()' may issue 'ieee80211freehw()' when one of 'rtwloadfirmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.(CVE-2024-47718)

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfcsliflushiorings(), lpfcdevlosstmocallbk(), or lpfcaborthandler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.(CVE-2024-49891)

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11ksocdpstats::halreoerror array is defined with a maximum size of DPREODSTRINGMAX. However, the ath11kdpprocessrx() function access ath11ksocdpstats::halreoerror using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11kdpprocessrx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-49930)

In the Linux kernel, the following vulnerability has been resolved: wifi: ath9khtc: Use _skbsetlength() for resetting urb before resubmit Syzbot points out that skbtrim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling _skbsetlength(skb, 0) directly. In addition, _skbsetlength() already contains a call to skbresettailpointer(), so remove the redundant call. The syzbot report came from ath9khifusbregincb(), but there's a similar usage of skbtrim() in ath9khifusbrxcb(), change both while we're at it.(CVE-2024-49938)

In the Linux kernel, the following vulnerability has been resolved: sctp: set skstate back to CLOSED if autobind fails in sctplistenstart In sctplistenstart() invoked by sctpinetlisten(), it should set the skstate back to CLOSED if sctpautobind() fails due to whatever reason. Otherwise, next time when calling sctpinetlisten(), if sctpsk(sk)->reuse is already set via setsockopt(SCTPREUSEPORT), sctpsk(sk)->bindhash will be dereferenced as skstate is LISTENING, which causes a crash as bindhash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctpinetlisten+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: <TASK> _syslistensocket net/socket.c:1883 [inline] _syslisten+0x1b7/0x230 net/socket.c:1894 _dosyslisten net/socket.c:1902 inline

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiqetop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skbput_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.(CVE-2024-49997)

In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlinkupdatesocketmc+0x3c/0xc0 LR [c000000000c0f764] _netlinkclearmulticastusers+0x74/0xc0 Call Trace: _netlinkclearmulticastusers+0x74/0xc0 genlunregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.(CVE-2024-50024)

In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCASTAB only for root qdisc Most qdiscs maintain their backlog using qdiscpktlen(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCASTAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: errorcode(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfqdequeue (net/sched/schsfq.c:272 net/sched/schsfq.c:499) schsfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ... Code starting with the faulting instruction =========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] <TASK> [ 88.808710] ? _die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? pagefaultoops (arch/x86/mm/fault.c:715) [ 88.809561] ? excpagefault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asmexcpagefault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfqdequeue (net/sched/schsfq.c:272 net/sched/schsfq.c:499) schsfq [ 88.810411] sfqreset (net/sched/schsfq.c:525) schsfq [ 88.810671] qdiscreset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/schg ---truncated---(CVE-2024-50039)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcommskstatechange rfcommskstatechange attempts to use socklock so it must never be called with it locked but rfcommsockioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sklock-AFBLUETOOTH-BTPROTORFCOMM){+.+.}-{0:0}, at: locksock include/net/sock.h:1671 [inline] ffff88807c396258 (sklock-AFBLUETOOTH-BTPROTORFCOMM){+.+.}-{0:0}, at: rfcommskstatechange+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: _rfcommdlcclose+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491(CVE-2024-50044)

In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix race condition between reset and nvmedevdisable() nvmedevdisable() modifies the dev->onlinequeues field, therefore nvmepciupdatenrqueues() should avoid racing against it, otherwise we could end up passing invalid values to blkmqupdatenrhwqueues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pciirqgetaffinity+0x187/0x210 Workqueue: nvme-reset-wq nvmeresetwork [nvme] RIP: 0010:pciirqgetaffinity+0x187/0x210 Call Trace: <TASK> ? blkmqpcimapqueues+0x87/0x3c0 ? pciirqgetaffinity+0x187/0x210 blkmqpcimapqueues+0x87/0x3c0 nvmepcimapqueues+0x189/0x460 [nvme] blkmqupdatenrhwqueues+0x2a/0x40 nvmeresetwork+0x1be/0x2a0 [nvme] Fix the bug by locking the shutdownlock mutex before using dev->onlinequeues. Give up if nvmedev_disable() is running or if it has been executed already.(CVE-2024-50135)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in protounregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:protounregister+0xee/0x400 Call Trace: <TASK> _dosysdeletemodule+0x318/0x580 dosyscall64+0xc1/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f As bnepinit() ignore bnepsockinit()'s return value, and bnepsockinit() will cleanup all resource. Then when remove bnep module will call bnepsockcleanup() to cleanup sock's resource. To solve above issue just return bnepsockinit()'s return value in bnepexit().(CVE-2024-50148)

In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcmsysportxmit() The bcmsysportxmit() returns NETDEVTXOK without freeing skb in case of dmamapsingle() fails, add devkfreeskb() to fix it.(CVE-2024-50171)

In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chainedirqenter() and chainedirqexit() if it detects pending interrupts. for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, &reg); if (!reg) continue; chained_irq_enter(parent_chip, desc); However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chainedirqenter() never gets called and the system hangs trying to service the parent interrupt. Moving chainedirqenter() and chainedirqexit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chainedirqenter() / chainedirqexit() functions wrapping interrupt checking loop may be found in many other drivers: grep -r -A 10 chained_irq_enter drivers/pinctrl(CVE-2024-50196)

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxtre: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when numpages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.(CVE-2024-50208)

In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxtre: Add a check for memory allocation _alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances.(CVE-2024-50209)

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: ilisr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965irqtasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RFKILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965irqtasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965macstart enter [ 12.052212] ieee80211 phy0: ilprepstation Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965sethwready hardware ready [ 12.052324] ieee80211 phy0: ilapminit Init card's basic functions [ 12.052348] ieee80211 phy0: ilapminit L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965loadbsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965verifybsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965verifybsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965loadbsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: _il4965up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965macstart Start UP work done. [ 12.058757] ieee80211 phy0: _il4965down iwl4965 is going down [ 12.058761] ieee80211 phy0: ilscancanceltimeout Scan cancel timeout [ 12.058762] ieee80211 phy0: ildoscanabort Not performing scan to abort [ 12.058765] ieee80211 phy0: ilclearucodestations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: ilclearucodestations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _ilapmstop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _ilapmstopmaster stop master [ 12.058864] ieee80211 phy0: il4965clearfreeframes 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: STARTALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm schfqcodel xttcpudp xtmultiport xtstate iptablefilter iptablenat nfnat nfconntrack nfdefragipv4 iptables xtables binfmtmisc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdhgeneric ecc iTCOwdt i2cdev iwl4965 iwlegacy coretemp sndhdacodecanalog pcspkr psmouse mac80211 sndhdacodecgeneric libarc4 sdhcipci cqhci sha256generic sdhci libsha256 firewireohci sndhdaintel sndinteldspcfg mmccore sndhdacodec sndhwdep firewirecore ledclass iosfmbi sndhdacore uhcihcd lpcich crcitut cfg80211 ehcipci ehcihcd sndpcm usbcore mfdcore rfkill sndtimer snd usbcommon soundcore video parportpc parport intelagp wmi intelgtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async asyncrunentryfn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---(CVE-2024-50234)

In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [<ffffffe6e7b245dc>] _kmemcacheallocnode+0x1e4/0x2d8 [<ffffffe6e7adde88>] kmalloctrace+0x48/0x110 [<ffffffe6bbd765fc>] ath10kwmitlvopgenmgmttxsend+0xd4/0x1d8 [ath10kcore] [<ffffffe6bbd3eed4>] ath10kmgmtoverwmitxwork+0x134/0x298 [ath10kcore] [<ffffffe6e78d5974>] processscheduledworks+0x1ac/0x400 [<ffffffe6e78d60b8>] workerthread+0x208/0x328 [<ffffffe6e78dc890>] kthread+0x100/0x1c0 [<ffffffe6e78166c0>] retfromfork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmtpendingtx idrremove() operation in ath10kwmitlvopcleanupmgmttxsend() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1(CVE-2024-50236)

In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctpsfootb() A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctpsfootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpdosm+0x181/0x93d0 net/sctp/smsideeffect.c:1166 sctpendpointbhrcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctpinqpush+0x2ef/0x380 net/sctp/inqueue.c:88 sctprcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4rcv+0x42/0x50 net/sctp/protocol.c:1159 ipprotocoldeliverrcu+0xb51/0x13d0 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x336/0x500 net/ipv4/ipinput.c:233(CVE-2024-50299)

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwlmvmsendrecoverycmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwlmvmsendcmdstatus(), which handles both size validation and frees the buffer.(CVE-2024-53059)

In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIGDVBDYNAMICMINORS is set or not. When not set, dvbregisterdevice() won't check for boundaries, as it will rely that a previous call to dvbregisteradapter() would already be enforcing it. On a similar way, dvbdevice_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.(CVE-2024-53063)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Never decrement pendingasynccopies on error The error flow in nfsd4copy() calls cleanupasynccopy(), which already decrements nn->pendingasync_copies.(CVE-2024-53073)

In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afswakeupasynccall() can incur lock recursion. The problem is that it is called from AFRXRPC whilst holding the ->notifylock, but it tries to take a ref on the afscall struct in order to pass it to a work queue - but if the afscall is already queued, we then have an extraneous ref that must be put... calling afsputcall() may call back down into AFRXRPC through rxrpckernelshutdowncall(), however, which might try taking the ->notifylock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .ownercpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <TASK> dumpstacklvl+0x47/0x70 dorawspinlock+0x3c/0x90 rxrpckernelshutdowncall+0x83/0xb0 afsputcall+0xd7/0x180 rxrpcnotifysocket+0xa0/0x190 rxrpcinputsplitjumbo+0x198/0x1d0 rxrpcinputdata+0x14b/0x1e0 ? rxrpcinputcallpacket+0xc2/0x1f0 rxrpcinputcallevent+0xad/0x6b0 rxrpcinputpacketonconn+0x1e1/0x210 rxrpcinputpacket+0x3f2/0x4d0 rxrpciothread+0x243/0x410 ? _pfxrxrpciothread+0x10/0x10 kthread+0xcf/0xe0 ? _pfxkthread+0x10/0x10 retfromfork+0x24/0x40 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>(CVE-2024-53090)

In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpflinkshowfdinfo() If a newly-added link type doesn't invoke BPFLINKTYPE(), accessing bpflinktypestrs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpflinkshow_fdinfo() and emitting a warning when such invocations are missed.(CVE-2024-53099)

In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in fromkuid and fromkgid ocfs2setattr() uses attr->iamode, attr->iauid and attr->iagid in a trace point even though ATTRMODE, ATTRUID and ATTRGID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTRMODE, ATTRUID, ATTRGID are initialized, otherwise 0.(CVE-2024-53101)