In the Linux kernel, the following vulnerability has been resolved:
crypto: xilinx - call finalize with bh disabled
When calling cryptofinalizerequest, BH should be disabled to avoid triggering the following calltrace:
------------[ cut here ]------------ WARNING: CPU: 2 PID: 74 at crypto/cryptoengine.c:58 cryptofinalizerequest+0xa0/0x118 Modules linked in: cryptodev(O) CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cryptofinalizerequest+0xa0/0x118 lr : cryptofinalizerequest+0x104/0x118 sp : ffffffc085353ce0 x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688 x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00 x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000 x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0 x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8 x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001 x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000 x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000 Call trace: cryptofinalizerequest+0xa0/0x118 cryptofinalizeaeadrequest+0x18/0x30 zynqmphandleaesreq+0xcc/0x388 cryptopumpwork+0x168/0x2d8 kthreadworkerfn+0xfc/0x3a0 kthread+0x118/0x138 retfromfork+0x10/0x20 irq event stamp: 40 hardirqs last enabled at (39): [<ffffffc0812416f8>] rawspinunlockirqrestore+0x70/0xb0 hardirqs last disabled at (40): [<ffffffc08122d208>] el1dbg+0x28/0x90 softirqs last enabled at (36): [<ffffffc080017dec>] kernelneonbegin+0x8c/0xf0 softirqs last disabled at (34): [<ffffffc080017dc0>] kernelneonbegin+0x60/0xf0 ---[ end trace 0000000000000000 ]---
In the Linux kernel, the following vulnerability has been resolved:
net: esp: fix bad handling of pages from pagepool
The Linux kernel CVE team has assigned CVE-2024-26953 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050128-CVE-2024-26953-8304@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
net: rswitch: Avoid use-after-free in rswitchpoll()
The use-after-free is actually in rswitchtxfree(), which is inlined in rswitchpoll(). Since skb and gq->skbs[gq->dirty] are in fact the same pointer, the skb is first freed using devkfreeskbany(), then the value in skb->len is used to update the interface statistics.
Let's move around the instructions to use skb->len before the skb is freed.
This bug is trivial to reproduce using KFENCE. It will trigger a splat every few packets. A simple ARP request or ICMP echo request is enough.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix possible double free in smb2setea()
Clang static checker(scan-build) warning： fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory. 1304 | kfree(ea); | ^~~~~~~~~
There is a double free in such case: 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto seaexit' -> 'first memory release for ea' -> 'goto replayagain' -> 'second goto seaexit before allocate memory for ea' -> 'second memory release for ea resulted in double free'.
Re-initialie 'ea' to NULL near to the replayagain label, it can fix this double free problem.
In the Linux kernel, the following vulnerability has been resolved:
bnxten: Fix aggregation ID mask to prevent oops on 5760X chips
The 5760X (P7) chip's HW GRO/LRO interface is very similar to that of the previous generation (5750X or P5). However, the aggregation ID fields in the completion structures on P7 have been redefined from 16 bits to 12 bits. The freed up 4 bits are redefined for part of the metadata such as the VLAN ID. The aggregation ID mask was not modified when adding support for P7 chips. Including the extra 4 bits for the aggregation ID can potentially cause the driver to store or fetch the packet header of GRO/LRO packets in the wrong TPA buffer. It may hit the BUG() condition in skbpull() because the SKB contains no valid packet header:
kernel BUG at include/linux/skbuff.h:2766! Oops: invalid opcode: 0000 1 PREEMPT SMP NOPTI CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Kdump: loaded Tainted: G OE 6.12.0-rc2+ #7 Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: Dell Inc. PowerEdge R760/0VRV9X, BIOS 1.0.1 12/27/2022 RIP: 0010:ethtypetrans+0xda/0x140 Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 d0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48 RSP: 0018:ff615003803fcc28 EFLAGS: 00010283 RAX: 00000000000022d2 RBX: 0000000000000003 RCX: ff2e8c25da334040 RDX: 0000000000000040 RSI: ff2e8c25c1ce8000 RDI: ff2e8c25869f9000 RBP: ff2e8c258c31c000 R08: ff2e8c25da334000 R09: 0000000000000001 R10: ff2e8c25da3342c0 R11: ff2e8c25c1ce89c0 R12: ff2e8c258e0990b0 R13: ff2e8c25bb120000 R14: ff2e8c25c1ce89c0 R15: ff2e8c25869f9000 FS: 0000000000000000(0000) GS:ff2e8c34be300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f05317e4c8 CR3: 000000108bac6006 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? die+0x33/0x90 ? dotrap+0xd9/0x100 ? ethtypetrans+0xda/0x140 ? doerrortrap+0x65/0x80 ? ethtypetrans+0xda/0x140 ? excinvalidop+0x4e/0x70 ? ethtypetrans+0xda/0x140 ? asmexcinvalidop+0x16/0x20 ? ethtypetrans+0xda/0x140 bnxttpaend+0x10b/0x6b0 [bnxten] ? bnxttpastart+0x195/0x320 [bnxten] bnxtrxpkt+0x902/0xd90 [bnxten] ? bnxttxint.constprop.0+0x89/0x300 [bnxten] ? kmemcachefree+0x343/0x440 ? bnxttxint.constprop.0+0x24f/0x300 [bnxten] bnxtpollwork+0x193/0x370 [bnxten] bnxtpollp5+0x9a/0x300 [bnxten] ? trytowakeup+0x209/0x670 napipoll+0x29/0x1b0
Fix it by redefining the aggregation ID mask for P5PLUS chips to be 12 bits. This will work because the maximum aggregation ID is less than 4096 on all P5PLUS chips.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: fix possible wrong descriptor completion in llistabortdesc()
At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks.
Fix this by completing d instead of found in the final listforeachentrysafe() loop.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix queryinfo() replay double-free
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2queryinfoinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double-free in SMB2ioctl() replay
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2ioctlinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix change notify replay double-free
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2notifyinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix query directory replay double-free
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2querydirectoryinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double-free in SMB2flush() replay
SMB2flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifssendrecv() stores a replacement response, flushexit will free the stale response pointer a second time.
Reinitialize respbuftype and rspiov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: fix RCU usage in connect path
With lockdep enabled, calls to the connect function from cfg802.11 layer lead to the following warning:
============================= WARNING: suspicious RCU usage 6.7.0-rc1-wt+ #333 Not tainted ----------------------------- drivers/net/wireless/microchip/wilc1000/hif.c:386 suspicious rcudereferencecheck() usage! [...] stack backtrace: CPU: 0 PID: 100 Comm: wpasupplicant Not tainted 6.7.0-rc1-wt+ #333 Hardware name: Atmel SAMA5 unwindbacktrace from showstack+0x18/0x1c showstack from dumpstacklvl+0x34/0x48 dumpstacklvl from wilcparsejoinbssparam+0x7dc/0x7f4 wilcparsejoinbssparam from connect+0x2c4/0x648 connect from cfg80211connect+0x30c/0xb74 cfg80211connect from nl80211connect+0x860/0xa94 nl80211connect from genlrcvmsg+0x3fc/0x59c genlrcvmsg from netlinkrcvskb+0xd0/0x1f8 netlinkrcvskb from genlrcv+0x2c/0x3c genlrcv from netlinkunicast+0x3b0/0x550 netlinkunicast from netlinksendmsg+0x368/0x688 netlinksendmsg from syssendmsg+0x190/0x430 syssendmsg from syssendmsg+0x110/0x158 syssendmsg from syssendmsg+0xe8/0x150 syssendmsg from retfastsyscall+0x0/0x1c
This warning is emitted because in the connect path, when trying to parse target BSS parameters, we dereference a RCU pointer whithout being in RCU critical section. Fix RCU dereference usage by moving it to a RCU read critical section. To avoid wrapping the whole wilcparsejoinbssparam under the critical section, just use the critical section to copy ies data
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: dbg-tlv: ensure NUL termination
The iwlfwinidebuginfotlv is used as a string, so we must ensure the string is terminated correctly before using it.
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix command flush on cable pull
System crash due to command failed to flush back to SCSI layer.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x8664 #1 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvmefcconnectctrlwork [nvmefc] RIP: 0010:wakeupcommon+0x4c/0x190 Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: wakeupcommonlock+0x7c/0xc0 qlanvmelsreq+0x355/0x4c0 [qla2xxx] qla2xxx [0000:12:00.1]-f084:3: qltfreesessiondone: sesess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loopid 0x02 sid 01:02:00 logout 1 keep 0 elslogo 0 ? nvmefcsendlsreq+0x260/0x380 [nvmefc] qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200. ? nvmefcsendlsreq.constprop.42+0x1a/0x45 [nvmefc] qla2xxx [0000:12:00.1]-2109:3: qla2x00schedulerportdel 21320002ac07eeb8. rport ffff8ae598122000 roles 1 ? nvmefcconnectctrlwork.cold.63+0x1e3/0xa7d [nvmefc] qla2xxx [0000:12:00.1]-f084:3: qltfreesessiondone: sesess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loopid 0x04 sid 01:02:01 logout 1 keep 0 elslogo 0 ? switchto+0x10c/0x450 ? processonework+0x1a7/0x360 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201. ? workerthread+0x1ce/0x390 ? createworker+0x1a0/0x1a0 qla2xxx [0000:12:00.1]-2109:3: qla2x00schedulerportdel 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70 ? kthread+0x10a/0x120 qla2xxx [0000:12:00.1]-2112:3: qlanvmeunregisterremoteport: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8 ? setkthreadstruct+0x40/0x40 qla2xxx [0000:12:00.1]-2110:3: remoteportdelete of ffff8ae14801e000 21320102adf7eeb8 completed. ? retfromfork+0x1f/0x40 qla2xxx [0000:12:00.1]-f086:3: qltfreesessiondone: waiting for sess ffff8ae14801e000 logout
The system was under memory stress where driver was not able to allocate an SRB to carry out error recovery of cable pull. The failure to flush causes upper layer to start modifying scsicmnd. When the system frees up some memory, the subsequent cable pull trigger another command flush. At this point the driver access a null pointer when attempting to DMA unmap the SGL.
Add a check to make sure commands are flush back on session tear down to prevent the null pointer access.
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix use-after-free bug in brcmfcfg80211detach
This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233
In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker:
->brcmfusbprobe ->brcmfusbprobecb ->brcmfattach ->brcmfbusstarted ->brcmfcfg80211attach ->wlinitpriv ->brcmfinitescan ->INITWORK(&cfg->escantimeoutwork, brcmfcfg80211escantimeoutworker);
If we disconnect the USB by hotplug, it will call brcmfusbdisconnect to make cleanup. The invoking chain is :
brcmfusbdisconnect ->brcmfusbdisconnectcb ->brcmfdetach ->brcmfcfg80211detach ->kfree(cfg);
While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmfcfg80211escantimeoutworker.
Fix it by deleting the timer and canceling the worker in brcmfcfg80211detach.
[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: Fix double-allocation of slots due to broken alignment handling
Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"), which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment checks"), causes a functional regression with vsock in a virtual machine using bouncing via a restricted DMA SWIOTLB pool.
When virtio allocates the virtqueues for the vsock device using dmaalloccoherent(), the SWIOTLB search can return page-unaligned allocations if 'area->index' was left unaligned by a previous allocation from the buffer:
# Final address in brackets is the SWIOTLB address returned to the caller | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800)
This ends badly (typically buffer corruption and/or a hang) because swiotlballoc() is expecting a page-aligned allocation and so blindly returns a pointer to the 'struct page' corresponding to the allocation, therefore double-allocating the first half (2KiB slot) of the 4KiB page.
Fix the problem by treating the allocation alignment separately to any additional alignment requirements from the device, using the maximum of the two as the stride to search the buffer slots and taking care to ensure a minimum of page-alignment for buffers larger than a page.
This also resolves swiotlb allocation failures occuring due to the inclusion of ~PAGEMASK in 'iotlbalignmask' for large allocations and resulting in alignment requirements exceeding swiotlbmaxmappingsize().
In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: fix crash in wacomaesbatteryhandler()
Commit fd2a9b29dc9c ("HID: wacom: Remove AES powersupply after extended inactivity") introduced wacomaesbatteryhandler() which is scheduled as a delayed work (aesbatterywork).
In wacomremove(), aesbatterywork is not canceled. Consequently, if the device is removed while aesbatterywork is still pending, then hard crashes or "Oops: general protection fault..." are experienced when wacomaesbatteryhandler() is finally called. E.g., this happens with built-in USB devices after resume from hibernate when aesbatterywork was still pending at the time of hibernation.
So, take care to cancel aesbatterywork in wacomremove().
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/pf: Clear all LMTT pages on alloc
Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages.
Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap.
While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle.
(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double-free in SMB2open() replay
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2openinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Add some bounds checking to firmware data
Smatch complains about "head->fullsize - head->headersize" can underflow. To some extent, we're always going to have to trust the firmware a bit. However, it's easy enough to add a check for negatives, and let's add a upper bounds check as well.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix potencial out-of-bounds when buffer offset is invalid
I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-out-of-bounds in smbstrndupfromutf16()
If ->NameOffset of smb2createreq is smaller than Buffer offset of smb2createreq, slab-out-of-bounds read can happen from smb2open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2createreq().
In the Linux kernel, the following vulnerability has been resolved:
mm, slub: do not call doslabfree for kfence object
In 782f8906f805 the freeing of kfence objects was moved from deep inside doslabfree to the wrapper functions outside. This is a nice change, but unfortunately it missed one spot in kmemcachefreebulk.
This results in a crash like this:
BUG skbuffheadcache (Tainted: G S B E ): Padding overwritten. 0xffff88907fea0f00-0xffff88907fea0fff @offset=3840
slaberr (mm/slub.c:1129) freetopartiallist (mm/slub.c:? mm/slub.c:4036) slabpadcheck (mm/slub.c:864 mm/slub.c:1290) checkslab (mm/slub.c:?) freetopartiallist (mm/slub.c:3171 mm/slub.c:4036) kmemcacheallocbulk (mm/slub.c:? mm/slub.c:4495 mm/slub.c:4586 mm/slub.c:4635) napibuildskb (net/core/skbuff.c:348 net/core/skbuff.c:527 net/core/skbuff.c:549)
All the other callers to doslabfree appear to be ok.
Add a kfencefree check in kmemcachefreebulk to avoid the crash.
In the Linux kernel, the following vulnerability has been resolved:
netdev: prevent accessing NAPI instances from another namespace
The NAPI IDs were not fully exposed to user space prior to the netlink API, so they were never namespaced. The netlink API must ensure that at the very least NAPI instance belongs to the same netns as the owner of the genl sock.
napibyid() can become static now, but it needs to move because of devgetbynapiid().
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
The Linux kernel CVE team has assigned CVE-2024-35789 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051707-CVE-2024-35789-52e5@gregkh/T
Integer overflow in raid5cachecount in Linux kernel
In the Linux kernel, the following vulnerability has been resolved:
usb: misc: ljca: Fix double free in error handling path
When auxiliarydeviceadd() returns error and then calls auxiliarydeviceuninit(), callback function ljcaauxdevrelease calls kfree(auxdev->dev.platformdata) to free the parameter data of the function ljcanewclientdevice. The callers of ljcanewclientdevice shouldn't call kfree() again in the error handling path to free the platform data.
Fix this by cleaning up the redundant kfree() in all callers and adding kfree() the passed in platformdata on errors which happen before auxiliarydeviceinit() succeeds .
In the Linux kernel, the following vulnerability has been resolved:
ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs
The dreamcastcard->timer could schedule the spudmawork and the spudmawork could also arm the dreamcastcard->timer.
When the sndpcmsubstream is closing, the aicachannel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that deltimer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below:
(Thread 1) | (Thread 2) sndaicapcmpcmclose() | ... | runspudma() //worker | modtimer() flushwork() | deltimer() | aicaperiodelapsed() //timer kfree(dreamcastcard->channel) | schedulework() | runspudma() //worker ... | dreamcastcard->channel-> //USE
In order to mitigate this bug and other possible corner cases, call modtimer() conditionally in runspudma(), then implement PCM syncstop op to cancel both the timer and worker. The syncstop op will be called from PCM core appropriately when needed.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftsetpipapo: release elements in clone only from destroy path
Clone already always provides a current view of the lookup table, use it to destroy the set, otherwise it is possible to destroy elements twice.
This fix requires:
212ed75dc5fb ("netfilter: nftables: integrate pipapo into commit protocol")
which came after:
9827a0e6e23b ("netfilter: nftsetpipapo: release elements in clone from abort path").