In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix race on per-CQ variable napi workdone
After calling napicompletedone(), the NAPIFSTATESCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->workdone. If the other thread (for example, from busypoll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic.
To fix this issue, save the per-CQ workdone variable in a local variable before napicompletedone(), so it won't be corrupted by a possible concurrent thread after napicompletedone().
Also, add a flag bit to advertise to the NIC firmware: the NAPI workdone variable race is fixed, so the driver is able to reliably support features like busypoll.
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix SRCU protection of nvmenshead list
Walking the nvmenshead siblings list is protected by the head's srcu in nvmensheadsubmitbio() but not nvmempathrevalidatepaths(). Removing namespaces from the list also fails to synchronize the srcu. Concurrent scan work can therefore cause use-after-frees.
Hold the head's srcu lock in nvmempathrevalidatepaths() and synchronize with the srcu, not the global RCU, in nvmensremove().
Observed the following panic when making NVMe/RDMA connections with native multipath on the Rocky Linux 8.6 kernel (it seems the upstream kernel has the same race condition). Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx; computing capacity != getcapacity(ns->disk). Address 0x50 is dereferenced because ns->disk is NULL. The NULL disk appears to be the result of concurrent scan work freeing the namespace (note the log line in the middle of the panic).
[37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [37314.206036] nvme0n3: detected capacity change from 0 to 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x8664 #1 [37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018 [37314.299763] Workqueue: nvme-wq nvmescanwork [nvmecore] [37314.299783] RIP: 0010:nvmempathrevalidatepaths+0x26/0xb0 [nvmecore] [37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Call Trace: [37315.828515] nvmeupdatensinfo+0x1ac/0x250 [nvmecore] [37315.892075] nvmevalidateorallocns+0x2ff/0xa00 [nvmecore] [37315.961871] ? blkmqfreerequest+0x6b/0x90 [37316.015021] nvmescanwork+0x151/0x240 [nvmecore] [37316.073371] processonework+0x1a7/0x360 [37316.121318] ? createworker+0x1a0/0x1a0 [37316.168227] workerthread+0x30/0x390 [37316.212024] ? createworker+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? setkthreadstruct+0x50/0x50 [37316.347590] retfromfork+0x35/0x40 [37316.390360] Modules linked in: nvmerdma nvmetcp(X) nvmefabrics nvmecore netconsole iscsitcp libiscsitcp dmqueuelength dmservicetime nfconntracknetlink brnetfilter bridge stp llc overlay nftchainnat iptMASQUERADE nfnat xtaddrtype xtCT nftcounter xtstate xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 xtcomment xtmultiport nftcompat nftables libcrc32c nfnetlink dmmultipath tg3 rpcrdma sunrpc rdmaucm ibsrpt ibisert iscsitargetmod targetcoremod ibiser libiscsi scsitransportiscsi ibumad rdmacm ibipoib iwcm ibcm intelraplmsr iTCOwdt iTCOvendorsupport dcdbas intelraplcommon sbedac x86pkgtempthermal intelpowerclamp coretemp kvmintel ipmissif kvm irqbypass crct10difpclmul crc32pclmul mlx5ib ghashclmulniintel ibuverbs rapl intelcstate inteluncore ibcore ipmisi joydev meime pcspkr ipmidevintf mei lpcich wmi ipmimsghandler acpipowermeter ex ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ceph: avoid putting the realm twice when decoding snaps fails
When decoding the snaps fails it maybe leaving the 'firstrealm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUGON, etc issues.
In the Linux kernel, the following vulnerability has been resolved:
skmsg: pass gfp argument to allocskmsg()
syzbot found that allocskmsg() could be called from a non sleepable context. skpsockverdictrecv() uses rcureadlock() protection.
We need the callers to pass a gfpt argument to avoid issues.
syzbot report was:
BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 inatomic(): 0, irqsdisabled(): 0, nonblock: 0, pid: 3613, name: syz-executor414 preemptcount: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e3/0x2cb lib/dumpstack.c:106 mightresched+0x538/0x6a0 kernel/sched/core.c:9877 mightalloc include/linux/sched/mm.h:274 [inline] slabpreallochook mm/slab.h:700 [inline] slaballocnode mm/slub.c:3162 [inline] slaballoc mm/slub.c:3256 [inline] kmemcachealloctrace+0x59/0x310 mm/slub.c:3287 kmalloc include/linux/slab.h:600 [inline] kzalloc include/linux/slab.h:733 [inline] allocskmsg net/core/skmsg.c:507 [inline] skpsockskbingressself+0x5c/0x330 net/core/skmsg.c:600 skpsockverdictapply+0x395/0x440 net/core/skmsg.c:1014 skpsockverdictrecv+0x34d/0x560 net/core/skmsg.c:1201 tcpreadskb+0x4a1/0x790 net/ipv4/tcp.c:1770 tcprcvestablished+0x129d/0x1a10 net/ipv4/tcpinput.c:5971 tcpv4dorcv+0x479/0xac0 net/ipv4/tcpipv4.c:1681 skbacklogrcv include/net/sock.h:1109 [inline] releasesock+0x1d8/0x4c0 net/core/sock.c:2906 releasesock+0x5d/0x1c0 net/core/sock.c:3462 tcpsendmsg+0x36/0x40 net/ipv4/tcp.c:1483 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline] syssendto+0x46d/0x5f0 net/socket.c:2117 dosyssendto net/socket.c:2129 [inline] sesyssendto net/socket.c:2125 [inline] x64syssendto+0xda/0xf0 net/socket.c:2125 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd
In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: fix use-after-free in hsci
KASAN found that addr was dereferenced after br2deveventwork was freed.
================================================================== BUG: KASAN: use-after-free in qethl2br2devworker+0x5ba/0x6b0 Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540 CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1 Hardware name: IBM 8561 T01 703 (LPAR) Workqueue: 0.0.8000event qethl2br2devworker Call Trace: [<000000016944d4ce>] dumpstacklvl+0xc6/0xf8 [<000000016942cd9c>] printaddressdescription.constprop.0+0x34/0x2a0 [<000000016942d118>] printreport+0x110/0x1f8 [<0000000167a7bd04>] kasanreport+0xfc/0x128 [<000000016938d79a>] qethl2br2devworker+0x5ba/0x6b0 [<00000001673edd1e>] processonework+0x76e/0x1128 [<00000001673ee85c>] workerthread+0x184/0x1098 [<000000016740718a>] kthread+0x26a/0x310 [<00000001672c606a>] retfromfork+0x8a/0xe8 [<00000001694711da>] retfromfork+0xa/0x40 Allocated by task 108338: kasansavestack+0x40/0x68 kasansettrack+0x36/0x48 kasankmalloc+0xa0/0xc0 qethl2switchdevevent+0x25a/0x738 atomicnotifiercallchain+0x9c/0xf8 brswitchdevfdbnotify+0xf4/0x110 fdbnotify+0x122/0x180 fdbaddentry.constprop.0.isra.0+0x312/0x558 brfdbadd+0x59e/0x858 rtnlfdbadd+0x58a/0x928 rtnetlinkrcvmsg+0x5f8/0x8d8 netlinkrcvskb+0x1f2/0x408 netlinkunicast+0x570/0x790 netlinksendmsg+0x752/0xbe0 socksendmsg+0xca/0x110 syssendmsg+0x510/0x6a8 syssendmsg+0x12a/0x180 syssendmsg+0xe6/0x168 dosyssocketcall+0x3c8/0x468 dosyscall+0x22c/0x328 dosyscall+0x94/0xf0 systemcall+0x82/0xb0 Freed by task 540: kasansavestack+0x40/0x68 kasansettrack+0x36/0x48 kasansavefreeinfo+0x4c/0x68 kasanslabfree+0x14e/0x1a8 kasanslabfree+0x24/0x30 kmemcachefree+0x168/0x338 qethl2br2devworker+0x154/0x6b0 processonework+0x76e/0x1128 workerthread+0x184/0x1098 kthread+0x26a/0x310 retfromfork+0x8a/0xe8 retfromfork+0xa/0x40 Last potentially related work creation: kasansavestack+0x40/0x68 kasanrecordauxstack+0xbe/0xd0 insertwork+0x56/0x2e8 queuework+0x4ce/0xd10 queueworkon+0xf4/0x100 qethl2switchdevevent+0x520/0x738 atomicnotifiercallchain+0x9c/0xf8 brswitchdevfdbnotify+0xf4/0x110 fdbnotify+0x122/0x180 fdbaddentry.constprop.0.isra.0+0x312/0x558 brfdbadd+0x59e/0x858 rtnlfdbadd+0x58a/0x928 rtnetlinkrcvmsg+0x5f8/0x8d8 netlinkrcvskb+0x1f2/0x408 netlinkunicast+0x570/0x790 netlinksendmsg+0x752/0xbe0 socksendmsg+0xca/0x110 syssendmsg+0x510/0x6a8 syssendmsg+0x12a/0x180 syssendmsg+0xe6/0x168 dosyssocketcall+0x3c8/0x468 dosyscall+0x22c/0x328 dosyscall+0x94/0xf0 systemcall+0x82/0xb0 Second to last potentially related work creation: kasansavestack+0x40/0x68 kasanrecordauxstack+0xbe/0xd0 kvfreecallrcu+0xb2/0x760 kernfsunlinkopenfile+0x348/0x430 kernfsfoprelease+0xc2/0x320 fput+0x1ae/0x768 taskworkrun+0x1bc/0x298 exittousermodeprepare+0x1a0/0x1a8 dosyscall+0x94/0xf0 systemcall+0x82/0xb0 The buggy address belongs to the object at 00000000fdcea400 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 64 bytes inside of 96-byte region [00000000fdcea400, 00000000fdcea460) The buggy address belongs to the physical page: page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff) raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00 raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 00000000fdcea380: fb fb fb fb fb fb f ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
NFC: nci: Bounds check struct nfctarget arrays
While running under CONFIGFORTIFYSOURCE=y, syzkaller reported:
memcpy: detected field-spanning write (size 129) of single field "target->sensfres" at net/nfc/nci/ntf.c:260 (size 18)
This appears to be a legitimate lack of bounds checking in nciaddnewprotocol(). Add the missing checks.
In the Linux kernel, the following vulnerability has been resolved:
net: hisilicon: Fix potential use-after-free in hisifemacrx()
The skb is delivered to napigroreceive() which may free it, after calling this, dereferencing skb may trigger use-after-free.
In the Linux kernel, the following vulnerability has been resolved:
ravb: Fix potential use-after-free in ravbrxgbeth()
The skb is delivered to napigroreceive() which may free it, after calling this, dereferencing skb may trigger use-after-free.
In the Linux kernel, the following vulnerability has been resolved:
net: hisilicon: Fix potential use-after-free in hix5hd2rx()
The skb is delivered to napigroreceive() which may free it, after calling this, dereferencing skb may trigger use-after-free.
In the Linux kernel, the following vulnerability has been resolved:
mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths
Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs don't hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free.
I'm marking this as addressing an issue introduced in commit f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of the security impact of this only came in commit 27e1f8273113 ("khugepaged: enable collapse pmd for pte-mapped THP"), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables.
In the Linux kernel, the following vulnerability has been resolved:
tipc: re-fetch skb cb after tipcmsgvalidate
As the call trace shows, the original skb was freed in tipcmsgvalidate(), and dereferencing the old skb cb would cause an use-after-free crash.
BUG: KASAN: use-after-free in tipccryptorcvcomplete+0x1835/0x2240 [tipc] Call Trace: <IRQ> tipccryptorcvcomplete+0x1835/0x2240 [tipc] tipccryptorcv+0xd32/0x1ec0 [tipc] tipcrcv+0x744/0x1150 [tipc] ... Allocated by task 47078: kmemcacheallocnode+0x158/0x4d0 allocskb+0x1c1/0x270 tipcbufacquire+0x1e/0xe0 [tipc] tipcmsgcreate+0x33/0x1c0 [tipc] tipclinkbuildprotomsg+0x38a/0x2100 [tipc] tipclinktimeout+0x8b8/0xef0 [tipc] tipcnodetimeout+0x2a1/0x960 [tipc] calltimerfn+0x2d/0x1c0 ... Freed by task 47078: tipcmsgvalidate+0x7b/0x440 [tipc] tipccryptorcvcomplete+0x4b5/0x2240 [tipc] tipccryptorcv+0xd32/0x1ec0 [tipc] tipcrcv+0x744/0x1150 [tipc]
This patch fixes it by re-fetching the skb cb from the new allocated skb after calling tipcmsgvalidate().
In the Linux kernel, the following vulnerability has been resolved:
net: hsr: Fix potential use-after-free
The skb is delivered to netifrx() which may free it, after calling this, dereferencing skb may trigger use-after-free.
In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Correctly move list in scdisable()
Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with scdisable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash.
The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen:
BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: scdisable+0x1ba/0x240 [hfi1] piofreeze+0x3d/0x60 [hfi1] handlefreeze+0x27/0x1b0 [hfi1] processonework+0x1b0/0x380 ? processonework+0x380/0x380 workerthread+0x30/0x360 ? processonework+0x380/0x380 kthread+0xd7/0x100 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x1f/0x30
The fix is to use the correct call to move the list.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2capreassemblesdu
Fix the race condition between the following two flows that run in parallel:
1. l2capreassemblesdu -> chan->ops->recv (l2capsockrecvcb) -> sockqueuercvskb.
2. btsockrecvmsg -> skbrecvdatagram, skbfreedatagram.
An SKB can be queued by the first flow and immediately dequeued and freed by the second flow, therefore the callers of l2capreassemblesdu can't use the SKB after that function returns. However, some places continue accessing struct l2capctrl that resides in the SKB's CB for a short time after l2capreassemblesdu returns, leading to a use-after-free condition (the stack trace is below, line numbers for kernel 5.19.8).
Fix it by keeping a local copy of struct l2capctrl.
BUG: KASAN: use-after-free in l2caprxstaterecv (net/bluetooth/l2capcore.c:6906) bluetooth Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hcirxwork [bluetooth] Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:107 (discriminator 4)) printreport.cold (mm/kasan/report.c:314 mm/kasan/report.c:429) ? l2caprxstaterecv (net/bluetooth/l2capcore.c:6906) bluetooth kasanreport (mm/kasan/report.c:162 mm/kasan/report.c:493) ? l2caprxstaterecv (net/bluetooth/l2capcore.c:6906) bluetooth l2caprxstaterecv (net/bluetooth/l2capcore.c:6906) bluetooth l2caprx (net/bluetooth/l2capcore.c:7236 net/bluetooth/l2capcore.c:7271) bluetooth retfromfork (arch/x86/entry/entry64.S:306) </TASK>
Allocated by task 43169: kasansavestack (mm/kasan/common.c:39) kasanslaballoc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) kmemcacheallocnode (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293) allocskb (net/core/skbuff.c:414) l2caprecvfrag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2capcore.c:8329) bluetooth l2caprecvacldata (net/bluetooth/l2capcore.c:8442) bluetooth hcirxwork (net/bluetooth/hcicore.c:3642 net/bluetooth/hcicore.c:3832) bluetooth processonework (kernel/workqueue.c:2289) workerthread (./include/linux/list.h:292 kernel/workqueue.c:2437) kthread (kernel/kthread.c:376) retfromfork (arch/x86/entry/entry64.S:306)
Freed by task 27920: kasansavestack (mm/kasan/common.c:39) kasansettrack (mm/kasan/common.c:45) kasansetfreeinfo (mm/kasan/generic.c:372) kasanslabfree (mm/kasan/common.c:368 mm/kasan/common.c:328) slabfreefreelisthook (mm/slub.c:1780) kmemcachefree (mm/slub.c:3536 mm/slub.c:3553) skbfreedatagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323) btsockrecvmsg (net/bluetooth/afbluetooth.c:295) bluetooth l2capsockrecvmsg (net/bluetooth/l2capsock.c:1212) bluetooth sockreaditer (net/socket.c:1087) newsyncread (./include/linux/fs.h:2052 fs/readwrite.c:401) vfsread (fs/readwrite.c:482) ksysread (fs/readwrite.c:620) dosyscall64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:120)
In the Linux kernel, the following vulnerability has been resolved:
x86/tdx: Panic on bad configs that #VE on "private" memory access
All normal kernel memory is "TDX private memory". This includes everything from kernel stacks to kernel text. Handling exceptions on arbitrary accesses to kernel memory is essentially impossible because they can happen in horribly nasty places like kernel entry/exit. But, TDX hardware can theoretically deliver a virtualization exception (#VE) on any access to private memory.
But, it's not as bad as it sounds. TDX can be configured to never deliver these exceptions on private memory with a "TD attribute" called ATTRSEPTVEDISABLE. The guest has no way to set this attribute, but it can check it.
Ensure ATTRSEPTVEDISABLE is set in early boot. panic() if it is unset. There is no sane way for Linux to run with this attribute clear so a panic() is appropriate.
There's small window during boot before the check where kernel has an early #VE handler. But the handler is only for port I/O and will also panic() as soon as it sees any other #VE, such as a one generated by a private memory access.
[ dhansen: Rewrite changelog and rebase on new tdxparsetdinfo(). Add Kirill's tested-by because I made changes since he wrote this. ]
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac8021: fix possible oob access in ieee80211getrateduration
Fix possible out-of-bound access in ieee80211getrateduration routine as reported by the following UBSAN report:
UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47 index 15 is out of range for type 'u16 [12]' CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017 Workqueue: mt76 mt76utxstatusdata [mt76usb] Call Trace: <TASK> showstack+0x4e/0x61 dumpstacklvl+0x4a/0x6f dumpstack+0x10/0x18 ubsanepilogue+0x9/0x43 ubsanhandleoutofbounds.cold+0x42/0x47 ieee80211getrateduration.constprop.0+0x22f/0x2a0 [mac80211] ? ieee80211txstatusext+0x32e/0x640 [mac80211] ieee80211calcrxairtime+0xda/0x120 [mac80211] ieee80211calctxairtime+0xb4/0x100 [mac80211] mt76x02sendtxstatus+0x266/0x480 [mt76x02lib] mt76x02txstatusdata+0x52/0x80 [mt76x02lib] mt76utxstatusdata+0x67/0xd0 [mt76usb] processonework+0x225/0x400 workerthread+0x50/0x3e0 ? processonework+0x400/0x400 kthread+0xe9/0x110 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30
In the Linux kernel, the following vulnerability has been resolved:
memcg: fix possible use-after-free in memcgwriteeventcontrol()
memcgwriteeventcontrol() accesses the dentry->dname of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access dname as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too.
Prior to 347c4a874710 ("memcg: remove cgroupevent->cft"), there was a call to filecft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from filecft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the dname and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's.
Fix the bug by resurrecting the file type check in filecft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type.
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: sja1105: avoid out of bounds access in sja1105initl2policing()
The SJA1105 family has 45 L2 policing table entries (SJA1105MAXL2POLICINGCOUNT) and SJA1110 has 110 (SJA1110MAXL2POLICINGCOUNT). Keeping the table structure but accounting for the difference in port count (5 in SJA1105 vs 10 in SJA1110) does not fully explain the difference. Rather, the SJA1110 also has L2 ingress policers for multicast traffic. If a packet is classified as multicast, it will be processed by the policer index 99 + SRCPORT.
The sja1105initl2policing() function initializes all L2 policers such that they don't interfere with normal packet reception by default. To have a common code between SJA1105 and SJA1110, the index of the multicast policer for the port is calculated because it's an index that is out of bounds for SJA1105 but in bounds for SJA1110, and a bounds check is performed.
The code fails to do the proper thing when determining what to do with the multicast policer of port 0 on SJA1105 (ds->numports = 5). The "mcast" index will be equal to 45, which is also equal to table->ops->maxentrycount (SJA1105MAXL2POLICINGCOUNT). So it passes through the check. But at the same time, SJA1105 doesn't have multicast policers. So the code programs the SHARINDX field of an out-of-bounds element in the L2 Policing table of the static config.
The comparison between index 45 and 45 entries should have determined the code to not access this policer index on SJA1105, since its memory wasn't even allocated.
With enough bad luck, the out-of-bounds write could even overwrite other valid kernel data, but in this case, the issue was detected using KASAN.
Kernel log:
sja1105 spi5.0: Probed switch chip: SJA1105Q ================================================================== BUG: KASAN: slab-out-of-bounds in sja1105setup+0x1cbc/0x2340 Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8 ... Workqueue: eventsunbound deferredprobeworkfunc Call trace: ... sja1105setup+0x1cbc/0x2340 dsaregisterswitch+0x1284/0x18d0 sja1105probe+0x748/0x840 ... Allocated by task 8: ... sja1105setup+0x1bcc/0x2340 dsaregisterswitch+0x1284/0x18d0 sja1105probe+0x748/0x840 ...
In the Linux kernel, the following vulnerability has been resolved:
perf: Fix perfpendingtask() UaF
Per syzbot it is possible for perfpendingtask() to run after the event is free()'d. There are two related but distinct cases:
- the taskwork was already queued before destroying the event; - destroying the event itself queues the taskwork.
The first cannot be solved using taskworkcancel() since perfrelease() itself might be called from a taskwork (fput), which means the current->taskworks list is already empty and taskworkcancel() won't be able to find the perfpendingtask() entry.
The simplest alternative is extending the perfevent lifetime to cover the taskwork.
The second is just silly, queueing a taskwork while you know the event is going away makes no sense and is easily avoided by re-arranging how the event is marked STATEDEAD and ensuring it goes through STATEOFF on the way down.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: avoid use-after-free in ip6fragment()
Blamed commit claimed rcureadlock() was held by ip6fragment() callers.
It seems to not be always true, at least for UDP stack.
syzbot reported:
BUG: KASAN: use-after-free in ip6dstidev include/net/ip6fib.h:245 [inline] BUG: KASAN: use-after-free in ip6fragment+0x2724/0x2770 net/ipv6/ip6output.c:951 Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618
CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd1/0x138 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:284 [inline] printreport+0x15e/0x45d mm/kasan/report.c:395 kasanreport+0xbf/0x1f0 mm/kasan/report.c:495 ip6dstidev include/net/ip6fib.h:245 [inline] ip6fragment+0x2724/0x2770 net/ipv6/ip6output.c:951 ip6finishoutput net/ipv6/ip6output.c:193 [inline] ip6finishoutput+0x9a3/0x1170 net/ipv6/ip6output.c:206 NFHOOKCOND include/linux/netfilter.h:291 [inline] ip6output+0x1f1/0x540 net/ipv6/ip6output.c:227 dstoutput include/net/dst.h:445 [inline] ip6localout+0xb3/0x1a0 net/ipv6/outputcore.c:161 ip6sendskb+0xbb/0x340 net/ipv6/ip6output.c:1966 udpv6sendskb+0x82a/0x18a0 net/ipv6/udp.c:1286 udpv6pushpendingframes+0x140/0x200 net/ipv6/udp.c:1313 udpv6sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6sendmsg+0x9d/0xe0 net/ipv6/afinet6.c:665 socksendmsgnosec net/socket.c:714 [inline] socksendmsg+0xd3/0x120 net/socket.c:734 sockwriteiter+0x295/0x3d0 net/socket.c:1108 callwriteiter include/linux/fs.h:2191 [inline] newsyncwrite fs/readwrite.c:491 [inline] vfswrite+0x9ed/0xdd0 fs/readwrite.c:584 ksyswrite+0x1ec/0x250 fs/readwrite.c:637 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x39/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7fde3588c0d9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9 RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000 </TASK>
Allocated by task 7618: kasansavestack+0x22/0x40 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 kasanslaballoc+0x82/0x90 mm/kasan/common.c:325 kasanslaballoc include/linux/kasan.h:201 [inline] slabpostallochook mm/slab.h:737 [inline] slaballocnode mm/slub.c:3398 [inline] slaballoc mm/slub.c:3406 [inline] kmemcachealloclru mm/slub.c:3413 [inline] kmemcachealloc+0x2b4/0x3d0 mm/slub.c:3422 dstalloc+0x14a/0x1f0 net/core/dst.c:92 ip6dstalloc+0x32/0xa0 net/ipv6/route.c:344 ip6rtpcpualloc net/ipv6/route.c:1369 [inline] rt6makepcpuroute net/ipv6/route.c:1417 [inline] ip6polroute+0x901/0x1190 net/ipv6/route.c:2254 pollookupfunc include/net/ip6fib.h:582 [inline] fib6rulelookup+0x52e/0x6f0 net/ipv6/fib6rules.c:121 ip6routeoutputflagsnoref+0x2e6/0x380 net/ipv6/route.c:2625 ip6routeoutputflags+0x76/0x320 net/ipv6/route.c:2638 ip6routeoutput include/net/ip6route.h:98 [inline] ip6dstlookuptail+0x5ab/0x1620 net/ipv6/ip6output.c:1092 ip6dstlookupflow+0x90/0x1d0 net/ipv6/ip6output.c:1222 ip6skdstlookupflow+0x553/0x980 net/ipv6/ip6output.c:1260 udpv6sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554 inet6sendmsg+0x9d/0xe0 net/ipv6/afinet6.c:665 socksendmsgnosec n ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
mm/gup: fix guppudrange() for dax
For dax pud, pudhuge() returns true on x86. So the function works as long as hugetlb is configured. However, dax doesn't depend on hugetlb. Commit 414fd080d125 ("mm/gup: fix guppmdrange() for dax") fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well.
This fixes the below kernel panic:
general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: <TASK> getuserpagesfast+0x1f/0x40 iovitergetpages+0xc6/0x3b0 ? mempoolalloc+0x5d/0x170 bioiovitergetpages+0x82/0x4e0 ? bvecalloc+0x91/0xc0 ? bioallocbioset+0x19a/0x2a0 blkdevdirectIO+0x282/0x480 ? iocompleterwcommon+0xc0/0xc0 ? filemaprangehaspage+0x82/0xc0 genericfiledirectwrite+0x9d/0x1a0 ? inodeupdatetime+0x24/0x30 genericfilewriteiter+0xbd/0x1e0 blkdevwriteiter+0xb4/0x150 ? ioimportiovec+0x8d/0x340 iowrite+0xf9/0x300 ioissuesqe+0x3c3/0x1d30 ? sysvecrescheduleipi+0x6c/0x80 ioqueuesqe+0x33/0x240 ? fget+0x76/0xa0 iosubmitsqes+0xe6a/0x18d0 ? fgetlight+0xd1/0x100 x64sysiouringenter+0x199/0x880 ? contexttrackingenter+0x1f/0x70 ? irqentryexittousermode+0x24/0x30 ? irqentryexit+0x1d/0x30 ? contexttrackingexit+0xe/0x70 dosyscall64+0x3b/0x90 entrySYSCALL64afterhwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be < snip > </TASK> ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internalgetuserpagesfast+0x340/0x990 < snip > Kernel panic - not syncing: Fatal exception Kernel Offset: disabled
In the Linux kernel, the following vulnerability has been resolved:
ASoC: ops: Check bounds for second channel in sndsocputvolswsx()
The bounds checks in sndsocputvolswsx() are only being applied to the first channel, meaning it is possible to write out of bounds values to the second channel in stereo controls. Add appropriate checks.
In the Linux kernel, the following vulnerability has been resolved:
drm/shmem-helper: Remove errant put in error path
drmgemshmemmmap() doesn't own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix array index out of bound error in DCN32 DML
[Why&How] LinkCapacitySupport array is indexed with the number of voltage states and not the number of max DPPs. Fix the error by changing the array declaration to use the correct (larger) array size of total number of voltage states.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix use-after-free during gpu recovery
[Why] [ 754.862560] refcountt: underflow; use-after-free. [ 754.862898] Call Trace: [ 754.862903] <TASK> [ 754.862913] amdgpujobfreecb+0xc2/0xe1 [amdgpu] [ 754.863543] drmschedmain.cold+0x34/0x39 [amdsched]
[How] The fwfence may be not init, check whether dmafenceinit is performed before job free
In the Linux kernel, the following vulnerability has been resolved:
fscache: Fix oops due to race with cookielru and usecookie
If a cookie expires from the LRU and the LRUDISCARD flag is set, but the state machine has not run yet, it's possible another thread can call fscacheusecookie and begin to use it.
When the cookieworker finally runs, it will see the LRUDISCARD flag set, transition the cookie->state to LRUDISCARDING, which will then withdraw the cookie. Once the cookie is withdrawn the object is removed the below oops will occur because the object associated with the cookie is now NULL.
Fix the oops by clearing the LRUDISCARD bit if another thread uses the cookie before the cookieworker runs.
BUG: kernel NULL pointer dereference, address: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x8664 #1 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Workqueue: eventsunbound netfsrreqwritetocachework [netfs] RIP: 0010:cachefilespreparewrite+0x28/0x90 [cachefiles] ... Call Trace: netfsrreqwritetocachework+0x11c/0x320 [netfs] processonework+0x217/0x3e0 workerthread+0x4a/0x3b0 kthread+0xd6/0x100
In the Linux kernel, the following vulnerability has been resolved:
powerpc/bpf/32: Fix Oops on tail call tests
testbpf tail call tests end up as:
testbpf: #0 Tail call leaf jited:1 85 PASS testbpf: #1 Tail call 2 jited:1 111 PASS testbpf: #2 Tail call 3 jited:1 145 PASS testbpf: #3 Tail call 4 jited:1 170 PASS testbpf: #4 Tail call load/store leaf jited:1 190 PASS testbpf: #5 Tail call load/store jited:1 BUG: Unable to handle kernel data access on write at 0xf1b4e000 Faulting instruction address: 0xbe86b710 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGESIZE=4K MMU=Hash PowerMac Modules linked in: testbpf(+) CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ #195 Hardware name: PowerMac3,1 750CL 0x87210 PowerMac NIP: be86b710 LR: be857e88 CTR: be86b704 REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+) MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28008242 XER: 00000000 DAR: f1b4e000 DSISR: 42000000 GPR00: 00000001 f1b4dfe0 c11d2280 00000000 00000000 00000000 00000002 00000000 GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8 GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000 GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00 NIP [be86b710] 0xbe86b710 LR [be857e88] runone+0xec/0x264 [testbpf] Call Trace: [f1b4dfe0] [00000002] 0x2 (unreliable) Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 0000000000000000 ]---
This is a tentative to write above the stack. The problem is encoutered with tests added by commit 38608ee7b690 ("bpf, tests: Add load store test case for tail call")
This happens because tail call is done to a BPF prog with a different stackdepth. At the time being, the stack is kept as is when the caller tail calls its callee. But at exit, the callee restores the stack based on its own properties. Therefore here, at each run, r1 is erroneously increased by 32 - 16 = 16 bytes.
This was done that way in order to pass the tail call count from caller to callee through the stack. As powerpc32 doesn't have a red zone in the stack, it was necessary the maintain the stack as is for the tail call. But it was not anticipated that the BPF frame size could be different.
Let's take a new approach. Use register r4 to carry the tail call count during the tail call, and save it into the stack at function entry if required. This means the input parameter must be in r3, which is more correct as it is a 32 bits parameter, then tail call better match with normal BPF function entry, the down side being that we move that input parameter back and forth between r3 and r4. That can be optimised later.
Doing that also has the advantage of maximising the common parts between tail calls and a normal function exit.
With the fix, tail call tests are now successfull:
testbpf: #0 Tail call leaf jited:1 53 PASS testbpf: #1 Tail call 2 jited:1 115 PASS testbpf: #2 Tail call 3 jited:1 154 PASS testbpf: #3 Tail call 4 jited:1 165 PASS testbpf: #4 Tail call load/store leaf jited:1 101 PASS testbpf: #5 Tail call load/store jited:1 141 PASS testbpf: #6 Tail call error path, max count reached jited:1 994 PASS testbpf: #7 Tail call count preserved across function calls jited:1 140975 PASS testbpf: #8 Tail call error path, NULL target jited:1 110 PASS testbpf: #9 Tail call error path, index out of range jited:1 69 PASS testbpf: testtailcalls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT'ed]
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix use-after-free when reverting termination table
When having multiple dests with termination tables and second one or afterwards fails the driver reverts usage of term tables but doesn't reset the assignment in attr->dests[numvportdests].termtbl which case a use-after-free when releasing the rule. Fix by resetting the assignment of termtbl to null.
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: fix buffer overflow in elem comparison
For vendor elements, the code here assumes that 5 octets are present without checking. Since the element itself is already checked to fit, we only need to check the length.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (ibmpex) Fix possible UAF when ibmpexregisterbmc() fails
Smatch report warning as follows:
drivers/hwmon/ibmpex.c:509 ibmpexregisterbmc() warn: '&data->list' not removed from list
If ibmpexfindsensors() fails in ibmpexregisterbmc(), data will be freed, but data->list will not be removed from driverdata.bmcdata, then list traversal may cause UAF.
Fix by removeing it from driverdata.bmcdata before free().