In the Linux kernel, the following vulnerability has been resolved:
net/sched: actapi: use RCU with deferred freeing for action lifecycle
When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.
Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:
0: mutexlock() <-- holds the idr lock 0: rcureadlock() 0: p = idrfind(idr, index) <-- action p is valid (RCU protects IDR) 0: mutexunlock() <-- releases the idr lock 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) <-- Action removed from IDR 1: mutexunlock() <-- mutex released allowing us to delete the action 1: tcfactioncleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcountincnotzero(&p->tcfarefcnt) <-- ouch, UAF p points to freed memory
This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcuhead to tcaction used in the deferral and introducing a callrcu() in the delete path to defer the final kfree().
Note: this is a revert of commit d7fb60b9cafb ("netsched: get rid of tcfarcu") but also modernization/simplification to directly use kfreercu().
Let's illustrate the new restored code path:
0: rcureadlock() 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) 1: mutexunlock() 1: callrcu(&p->tcfarcu, tcfactionrcufree) <-- defer kfree after grace period 0: p = idrfind(idr, index) 0: refcountincnotzero(&p->tcfarefcnt) <-- fails, refcnt already 0 1: rcureadunlock() <-- release so freeing can run after grace period
After CPU1 calls idrremove(), the object is no longer reachable through the IDR. CPU0's subsequent idrfind() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.
In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usbparsessendpointcompanion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the fields in the descriptor.
Bluetooth: hciconn: fix potential UAF in createbigsync
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Implement ref count for SRB
The timeout handler and the done function are racing. When qla2x00asynciocbtimeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xxasyncgpscspdone() releases the SRB unconditionally. When scheduling back to qla2x00asynciocbtimeout() qla24xxasyncabortcmd() will access an freed sp->qpair pointer:
qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xxhandlegpscevent 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xxasyncabortcmd+0x1b/0x1c0 [qla2xxx]
Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks.
When we are able to cancel a timer (deltimer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one.
If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling krefput().
In the Linux kernel, the following vulnerability has been resolved:
tun: free page on buildskb failure in tunxdpone()
When buildskb() fails in tunxdpone(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhostnetbuildxdp() allocated for the frame. As with the short-frame rejection path, tunsendmsg() discards the per-buffer error and still returns totallen, so vhosttxbatch() takes the success path and never frees the page. Each buildskb() failure in a batch leaks one page-frag chunk.
Free the page before taking the error path, matching the putpage() the other error exits of tunxdpone() already perform.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read
The q54sj108a2debugfsread function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'datachar' as the source.
Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2CSMBUSBLOCKMAX + 2), this writes 30 bytes past the end of the buffer onto the stack.
Additionally, the arguments were swapped: it was reading from the zero-initialized 'datachar' and writing to 'data', resulting in all-zero output regardless of the actual I2C read.
Fix this by: 1. Expanding 'datachar' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simplereadfrombuffer call.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix in-place encryption corruption in SMB2write()
SMB2write() places write payload in iov[1..n] as part of rqiov. smb3inittransformrq() pointer-shares rqiov, so cryptmessage() encrypts iov[1] in-place, replacing the original plaintext with ciphertext. On a replayable error, the retry sends the same iov[1] which now contains ciphertext instead of the original data, resulting in corruption.
The corruption is most likely to be observed when connections are unstable, as reconnects trigger write retries that re-send the already-encrypted data.
This affects SFU mknod, MF symlinks, etc. On kernels before 6.10 (prior to the netfs conversion), sync writes also used this path and were similarly affected. The async write path wasn't unaffected as it uses rqiter which gets deep-copied.
Fix by moving the write payload into rqiter via ioviterkvec(), so smb3inittransformrq() deep-copies it before encryption.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix buffer validation by including null terminator size in EA length
The smb2setea function, which handles Extended Attributes (EA), was performing buffer validation checks that incorrectly omitted the size of the null terminating character (+1 byte) for EA Name. This patch fixes the issue by explicitly adding '+ 1' to EaNameLength where the null terminator is expected to be present in the buffer, ensuring the validation accurately reflects the total required buffer size.
In the Linux kernel, the following vulnerability has been resolved:
virtio-net: ensure the received length does not exceed allocated size
In xdplinearizepage, when reading the following buffers from the ring, we forget to check the received length with the true allocate size. This can lead to an out-of-bound read. This commit adds that missing check.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlennotify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.
The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:
tc qdisc add dev lo root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo parent 1: classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1 tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0 tc qdisc add dev lo parent 2:1 handle 3: netem tc qdisc add dev lo parent 3:1 handle 4: blackhole
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 tc class delete dev lo classid 1:1 echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisctreereducebacklog always calls qlennotify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdiscreset() and / or qdiscpurgequeue() which ultimately resets its qlen to 0 thus causing the following qdisctreereducebacklog() to report to the parent. Note that this may call qlennotify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlennotify() handlers idempotent.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/bpf: fix JIT code size calculation of bpf trampoline
archbpftrampolinesize() provides JIT size of the BPF trampoline before the buffer for JIT'ing it is allocated. The total number of instructions emitted for BPF trampoline JIT code depends on where the final image is located. So, the size arrived at with the dummy pass in archbpftrampolinesize() can vary from the actual size needed in archpreparebpftrampoline(). When the instructions accounted in archbpftrampolinesize() is less than the number of instructions emitted during the actual JIT compile of the trampoline, the below warning is produced:
WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpfjitcomp.c:981 archpreparebpftrampoline.isra.0+0xd2c/0xdcc
which is:
/ Make sure the trampoline generation logic doesn't overflow / if (image && WARNONONCE(&image[ctx->idx] > (u32 )rwimageend - BPFINSNSAFETY)) {
So, during the dummy pass, instead of providing some arbitrary image location, account for maximum possible instructions if and when there is a dependency with image location for JIT'ing.
calipso: Fix null-ptr-deref in calipsoreq{set,del}attr().
In the Linux kernel, the following vulnerability has been resolved:
schhfsc: make hfscqlennotify() idempotent
hfscqlennotify() is not idempotent either and not friendly to its callers, like fqcodeldequeue(). Let's make it idempotent to ease qdisctreereducebacklog() callers' life:
1. updatevf() decreases cl->clnactive, so we can check whether it is non-zero before calling it.
2. eltreeremove() always removes RB node cl->elnode, but we can use RBEMPTYNODE() + RBCLEARNODE() to make it safe.
In the Linux kernel, the following vulnerability has been resolved:
net: fix udp gso skbsegment after pull from fraglist
Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from fraglist") detected invalid geometry in fraglist skbs and redirects them from skbsegmentlist to more robust skbsegment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skbsegment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust.
If only part of the fraglist payload is pulled into headskb, it will always cause exception when splitting skbs by skbsegment. For detailed call stack information, see below.
Valid SKBGSOFRAGLIST skbs - consist of two or more segments - the headskb holds the protocol headers plus first gsosize - one or more fraglist skbs hold exactly one segment - all but the last must be gsosize
Optional datapath hooks such as NAT and BPF (bpfskbpulldata) can modify fraglist skbs, breaking these invariants.
In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes.
The skbs no longer meets the above SKBGSOFRAGLIST conditions because payload was pulled into headskb, it needs to be linearized before pass to regular skbsegment.
skbsegment+0xcd0/0xd14 udpgsosegment+0x334/0x5f4 udp4ufofragment+0x118/0x15c inetgsosegment+0x164/0x338 skbmacgsosegment+0xc4/0x13c skbgsosegment+0xc4/0x124 validatexmitskb+0x9c/0x2c0 validatexmitskblist+0x4c/0x80 schdirectxmit+0x70/0x404 devqueuexmit+0x64c/0xe5c neighresolveoutput+0x178/0x1c4 ipfinishoutput2+0x37c/0x47c ipfinishoutput+0x194/0x240 ipfinishoutput+0x20/0xf4 ipoutput+0x100/0x1a0 NFHOOK+0xc4/0x16c ipforward+0x314/0x32c iprcv+0x90/0x118 netifreceiveskb+0x74/0x124 processbacklog+0xe8/0x1a4 napipoll+0x5c/0x1f8 netrxaction+0x154/0x314 handlesoftirqs+0x154/0x4b8
[118.376811] [C201134] rxq0pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0pus: [name:mrdump&]PHYSOFFSET: 0x40000000 [118.470827] [C201134] rxq0pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0pus: [name:mrdump&]pc : [0xffffffd79598aefc] skbsegment+0xcd0/0xd14 [118.470900] [C201134] rxq0pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skbsegment+0x3bc/0xd14 [118.470928] [C201134] rxq0pus: [name:mrdump&]sp : ffffffc008013770
In the Linux kernel, the following vulnerability has been resolved:
espintcp: remove encap socket caching to avoid reference leak
The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns.
The reference chain is: xfrmstate -> enacpsk -> netns
Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket.
This patch results in a small (~2% in my tests) performance regression.
A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.
codel: remove sch->q.qlen check before qdisctreereducebacklog()
In the Linux kernel, the following vulnerability has been resolved:
mm/gup: reject FOLLSPLITPMD with hugetlb VMAs
Patch series "mm: fixes for device-exclusive entries (hmm)", v2.
Discussing the PageTail() call in makedeviceexclusiverange() with Willy, I recently discovered [1] that device-exclusive handling does not properly work with THP, making the hmm-tests selftests fail if THPs are enabled on the system.
Looking into more details, I found that hugetlb is not properly fenced, and I realized that something that was bugging me for longer -- how device-exclusive entries interact with mapcounts -- completely breaks migration/swapout/split/hwpoison handling of these folios while they have device-exclusive PTEs.
The program below can be used to allocate 1 GiB worth of pages and making them device-exclusive on a kernel with CONFIGTESTHMM.
Once they are device-exclusive, these folios cannot get swapped out (proc$pid/smapsrollup will always indicate 1 GiB RSS no matter how much one forces memory reclaim), and when having a memory block onlined to ZONEMOVABLE, trying to offline it will loop forever and complain about failed migration of a page that should be movable.
echo offline > /sys/devices/system/memory/memory136/state echo onlinemovable > /sys/devices/system/memory/memory136/state ./hmm-swap & ... wait until everything is device-exclusive echo offline > /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [ 285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [ 285.209072][T14882] pageowner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfpmask 0x140dca(GFPHIGHUSERMOVABLE|GFPCOMP|GFPZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, freets 227402023774 [ 285.216765][T14882] postallochook+0x197/0x1b0 [ 285.218874][T14882] getpagefromfreelist+0x76e/0x3280 [ 285.220864][T14882] allocfrozenpagesnoprof+0x38e/0x2740 [ 285.223302][T14882] allocpagesmpol+0x1fc/0x540 [ 285.225130][T14882] folioallocmpolnoprof+0x36/0x340 [ 285.227222][T14882] vmaallocfolionoprof+0xee/0x1a0 [ 285.229074][T14882] handlemmfault+0x2b38/0x56a0 [ 285.230822][T14882] handlemmfault+0x368/0x9f0 ...
This series fixes all issues I found so far. There is no easy way to fix without a bigger rework/cleanup. I have a bunch of cleanups on top (some previous sent, some the result of the discussion in v1) that I will send out separately once this landed and I get to it.
I wish we could just use some special present PROTNONE PTEs instead of these (non-present, non-none) fake-swap entries; but that just results in the same problem we keep having (lack of spare PTE bits), and staring at other similar fake-swap entries, that ship has sailed.
With this series, makedeviceexclusive() doesn't actually belong into mm/rmap.c anymore, but I'll leave moving that for another day.
I only tested this series with the hmm-tests selftests due to lack of HW, so I'd appreciate some testing, especially if the interaction between two GPUs wanting a device-exclusive entry works as expected.
<program> #include <stdio.h> #include <fcntl.h> #include <stdint.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <sys/mman.h> #include <sys/ioctl.h> #include <linux/types.h> #include <linux/ioctl.h>
#define HMMDMIRROREXCLUSIVE IOWR('H', 0x05, struct hmmdmirrorcmd)
struct hmmdmirrorcmd { u64 addr; u64 ptr; u64 npages; u64 cpages; u64 faults; };
const sizet size = 1 1024 1024 1024ul; const sizet chunksize = 2 1024 1024ul;
int m ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
keys: Fix UAF in keyput()
Once a key's reference count has been reduced to 0, the garbage collector thread may destroy it at any time and so keyput() is not allowed to touch the key after that point. The most keyput() is normally allowed to do is to touch keygcwork as that's a static global variable.
However, in an effort to speed up the reclamation of quota, this is now done in keyput() once the key's usage is reduced to 0 - but now the code is looking at the key after the deadline, which is forbidden.
Fix this by using a flag to indicate that a key can be gc'd now rather than looking at the key's refcount in the garbage collector.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free on inode when scanning root during em shrinking
At btrfsscanroot() we are accessing the inode's root (and fsinfo) in a call to btrfsfsclosing() after we have scheduled the inode for a delayed iput, and that can result in a use-after-free on the inode in case the cleaner kthread does the iput before we dereference the inode in the call to btrfsfsclosing().
Fix this by using the fsinfo stored already in a local variable instead of doing inode->root->fsinfo.
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fixed hclgefetchpfreg accesses bar space out of bounds issue
The TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs 1024-1279 are in different BAR space addresses. However, hclgefetchpfreg does not distinguish the tqp space information when reading the tqp space information. When the number of TQPs is greater than 1024, access bar space overwriting occurs. The problem of different segments has been considered during the initialization of tqp.iobase. Therefore, tqp.iobase is directly used when the queue is read in hclgefetchpfreg.
The error message:
Unable to handle kernel paging request at virtual address ffff800037200000 pc : hclgefetchpfreg+0x138/0x250 [hclge] lr : hclgegetregs+0x84/0x1d0 [hclge] Call trace: hclgefetchpfreg+0x138/0x250 [hclge] hclgegetregs+0x84/0x1d0 [hclge] hns3getregs+0x2c/0x50 [hns3] ethtoolgetregs+0xf4/0x270 devethtool+0x674/0x8a0 devioctl+0x270/0x36c sockdoioctl+0x110/0x2a0 sockioctl+0x2ac/0x530 arm64sysioctl+0xa8/0x100 invokesyscall+0x4c/0x124 el0svccommon.constprop.0+0x140/0x15c doel0svc+0x30/0xd0 el0svc+0x1c/0x2c el0synchandler+0xb0/0xb4 el0sync+0x168/0x180
In the Linux kernel, the following vulnerability has been resolved:
net: avoid potential UAF in defaultoperstate()
syzbot reported an UAF in defaultoperstate() [1]
Issue is a race between device and netns dismantles.
After calling rtnlunlock() from netdevruntodo(), we can not assume the netns of each device is still alive.
Make sure the device is not in NETREGUNREGISTERED state, and add an ASSERTRTNL() before the call to devgetbyindex().
We might move this ASSERTRTNL() in devgetbyindex() in the future.
[1]
BUG: KASAN: slab-use-after-free in devgetbyindex+0x5d/0x110 net/core/dev.c:852 Read of size 8 at addr ffff888043eba1b0 by task syz.0.0/5339
CPU: 0 UID: 0 PID: 5339 Comm: syz.0.0 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 devgetbyindex+0x5d/0x110 net/core/dev.c:852 defaultoperstate net/core/linkwatch.c:51 [inline] rfc2863policy+0x224/0x300 net/core/linkwatch.c:67 linkwatchdodev+0x3e/0x170 net/core/linkwatch.c:170 netdevruntodo+0x461/0x1000 net/core/dev.c:10894 rtnlunlock net/core/rtnetlink.c:152 [inline] rtnlnetunlock include/linux/rtnetlink.h:133 [inline] rtnldellink+0x760/0x8d0 net/core/rtnetlink.c:3520 rtnetlinkrcvmsg+0x791/0xcf0 net/core/rtnetlink.c:6911 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2541 netlinkunicastkernel net/netlink/afnetlink.c:1321 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1347 netlinksendmsg+0x8e4/0xcb0 net/netlink/afnetlink.c:1891 socksendmsgnosec net/socket.c:711 [inline] socksendmsg+0x221/0x270 net/socket.c:726 syssendmsg+0x52a/0x7e0 net/socket.c:2583 syssendmsg net/socket.c:2637 [inline] syssendmsg+0x269/0x350 net/socket.c:2669 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f2a3cb80809 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f2a3d9cd058 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f2a3cd45fa0 RCX: 00007f2a3cb80809 RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000008 RBP: 00007f2a3cbf393e R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f2a3cd45fa0 R15: 00007ffd03bc65c8 </TASK>
Allocated by task 5339: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] kasankmalloc+0x98/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] kmalloccachenoprof+0x243/0x390 mm/slub.c:4314 kmallocnoprof include/linux/slab.h:901 [inline] kmallocarraynoprof include/linux/slab.h:945 [inline] netdevcreatehash net/core/dev.c:11870 [inline] netdevinit+0x10c/0x250 net/core/dev.c:11890 opsinit+0x31e/0x590 net/core/netnamespace.c:138 setupnet+0x287/0x9e0 net/core/netnamespace.c:362 copynetns+0x33f/0x570 net/core/netnamespace.c:500 createnewnamespaces+0x425/0x7b0 kernel/nsproxy.c:110 unsharensproxynamespaces+0x124/0x180 kernel/nsproxy.c:228 ksysunshare+0x57d/0xa70 kernel/fork.c:3314 dosysunshare kernel/fork.c:3385 [inline] sesysunshare kernel/fork.c:3383 [inline] x64sysunshare+0x38/0x40 kernel/fork.c:3383 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x8 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Mark inode as bad as soon as error detected in mienumattr()
Extended the mienumattr() function interface with an additional parameter, struct ntfsinode ni, to allow marking the inode as bad as soon as an error is detected.
In the Linux kernel, the following vulnerability has been resolved:
mtd: core: add missing ofnodeget() in dynamic partitions code
This fixes unbalanced ofnodeput(): [ 1.078910] 6 cmdlinepart partitions found on MTD device gpmi-nand [ 1.085116] Creating 6 MTD partitions on "gpmi-nand": [ 1.090181] 0x000000000000-0x000008000000 : "nandboot" [ 1.096952] 0x000008000000-0x000009000000 : "nandfit" [ 1.103547] 0x000009000000-0x00000b000000 : "nandkernel" [ 1.110317] 0x00000b000000-0x00000c000000 : "nanddtb" [ 1.115525] ------------[ cut here ]------------ [ 1.120141] refcountt: addition on 0; use-after-free. [ 1.125328] WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcountwarnsaturate+0xdc/0x148 [ 1.133528] Modules linked in: [ 1.136589] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7-next-20220930-04543-g8cf3f7 [ 1.146342] Hardware name: Freescale i.MX8DXL DDR3L EVK (DT) [ 1.151999] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158965] pc : refcountwarnsaturate+0xdc/0x148 [ 1.163760] lr : refcountwarnsaturate+0xdc/0x148 [ 1.168556] sp : ffff800009ddb080 [ 1.171866] x29: ffff800009ddb080 x28: ffff800009ddb35a x27: 0000000000000002 [ 1.179015] x26: ffff8000098b06ad x25: ffffffffffffffff x24: ffff0a00ffffff05 [ 1.186165] x23: ffff00001fdf6470 x22: ffff800009ddb367 x21: 0000000000000000 [ 1.193314] x20: ffff00001fdfebe8 x19: ffff00001fdfec50 x18: ffffffffffffffff [ 1.200464] x17: 0000000000000000 x16: 0000000000000118 x15: 0000000000000004 [ 1.207614] x14: 0000000000000fff x13: ffff800009bca248 x12: 0000000000000003 [ 1.214764] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 4762cb2ccb52de00 [ 1.221914] x8 : 4762cb2ccb52de00 x7 : 205d313431303231 x6 : 312e31202020205b [ 1.229063] x5 : ffff800009d55c1f x4 : 0000000000000001 x3 : 0000000000000000 [ 1.236213] x2 : 0000000000000000 x1 : ffff800009954be6 x0 : 000000000000002a [ 1.243365] Call trace: [ 1.245806] refcountwarnsaturate+0xdc/0x148 [ 1.250253] kobjectget+0x98/0x9c [ 1.253658] ofnodeget+0x20/0x34 [ 1.257072] offwnodeget+0x3c/0x54 [ 1.260652] fwnodegetnthparent+0xd8/0xf4 [ 1.264926] fwnodefullnamestring+0x3c/0xb4 [ 1.269373] devicenodestring+0x498/0x5b4 [ 1.273561] pointer+0x41c/0x5d0 [ 1.276793] vsnprintf+0x4d8/0x694 [ 1.280198] vprintkstore+0x164/0x528 [ 1.283951] vprintkemit+0x98/0x164 [ 1.287530] vprintkdefault+0x44/0x6c [ 1.291284] vprintk+0xf0/0x134 [ 1.294428] printk+0x54/0x7c [ 1.297486] ofnoderelease+0xe8/0x128 [ 1.301326] kobjectput+0x98/0xfc [ 1.304732] ofnodeput+0x1c/0x28 [ 1.308137] addmtddevice+0x484/0x6d4 [ 1.311977] addmtdpartitions+0xf0/0x1d0 [ 1.316078] parsemtdpartitions+0x45c/0x518 [ 1.320439] mtddeviceparseregister+0xb0/0x274 [ 1.325147] gpminandprobe+0x51c/0x650 [ 1.329074] platformprobe+0xa8/0xd0 [ 1.332740] reallyprobe+0x130/0x334 [ 1.336406] driverprobedevice+0xb4/0xe0 [ 1.340681] driverprobedevice+0x3c/0x1f8 [ 1.344869] driverattach+0xdc/0x1a4 [ 1.348708] busforeachdev+0x80/0xcc [ 1.352548] driverattach+0x24/0x30 [ 1.356127] busadddriver+0x108/0x1f4 [ 1.359967] driverregister+0x78/0x114 [ 1.363807] platformdriverregister+0x24/0x30 [ 1.368515] gpminanddriverinit+0x1c/0x28 [ 1.372798] dooneinitcall+0xbc/0x238 [ 1.376638] doinitcalllevel+0x94/0xb4 [ 1.380565] doinitcalls+0x54/0x94 [ 1.384058] dobasicsetup+0x1c/0x28 [ 1.387724] kernelinitfreeable+0x110/0x188 [ 1.392084] kernelinit+0x20/0x1a0 [ 1.395578] retfromfork+0x10/0x20 [ 1.399157] ---[ end trace 0000000000000000 ]--- [ 1.403782] ------------[ cut here ]------------
In the Linux kernel, the following vulnerability has been resolved:
writeback: avoid use-after-free after removing device
When a disk is removed, bdiunregister gets called to stop further writeback and wait for associated delayed work to complete. However, wbinodewritebackend() may schedule bandwidth estimation dwork after this has completed, which can result in the timer attempting to access the just freed bdiwriteback.
Fix this by checking if the bdiwriteback is alive, similar to when scheduling writeback work.
Since this requires wb->worklock, and wbinodewritebackend() may get called from interrupt, switch wb->worklock to an irqsafe lock.
In the Linux kernel, the following vulnerability has been resolved:
net: gso: fix panic on fraglist with mixed head alloc types
Since commit 3dcbdb134f32 ("net: gso: Fix skbsegment splat when splitting gsosize mangled skb having linear-headed fraglist"), it is allowed to change gsosize of a GRO packet. However, that commit assumes that "checking the first listskb member suffices; i.e if either of the listskb members have non headfrag head, then the first one has too".
It turns out this assumption does not hold. We've seen BUGON being hit in skbsegment when skbs on the fraglist had differing headfrag with the vmxnet3 driver. This happens because netdevallocskb and napiallocskb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced.
There are three different locations where this can be fixed:
(1) We could check headfrag in GRO and not allow GROing skbs with different headfrag. However, that would lead to performance regression on normal forward paths with unmodified gsosize, where !headfrag in the last packet is not a problem.
(2) Set a flag in bpfskbnetgrow and bpfskbnetshrink indicating that NETIFFSG is undesirable. That would need to eat a bit in skbuff. Furthermore, that flag can be unset when all skbs on the fraglist are page backed. To retain good performance, bpfskbnetgrow/shrink would have to walk the fraglist.
(3) Walk the fraglist in skbsegment when determining whether NETIFFSG should be cleared. This of course slows things down.
This patch implements (3). To limit the performance impact in skbsegment, the list is walked only for skbs with SKBGSODODGY set that have gsosize changed. Normal paths thus will not hit it.
We could check only the last skb but since we need to walk the whole list anyway, let's stay on the safe side.
In the Linux kernel, the following vulnerability has been resolved:
fbdev: defio: fix the pagelist corruption
Easily hit the below list corruption: == listadd corruption. prev->next should be next (ffffffffc0ceb090), but was ffffec604507edc8. (prev=ffffec604507edc8). WARNING: CPU: 65 PID: 3959 at lib/listdebug.c:26 listaddvalid+0x53/0x80 CPU: 65 PID: 3959 Comm: fbdev Tainted: G U RIP: 0010:listaddvalid+0x53/0x80 Call Trace: <TASK> fbdeferrediomkwrite+0xea/0x150 dopagemkwrite+0x57/0xc0 dowppage+0x278/0x2f0 handlemmfault+0xdc2/0x1590 handlemmfault+0xdd/0x2c0 douseraddrfault+0x1d3/0x650 excpagefault+0x77/0x180 ? asmexcpagefault+0x8/0x30 asmexcpagefault+0x1e/0x30 RIP: 0033:0x7fd98fc8fad1 ==
Figure out the race happens when one process is adding &page->lru into the pagelist tail in fbdeferrediomkwrite(), another process is re-initializing the same &page->lru in fbdeferrediofault(), which is not protected by the lock.
This fix is to init all the page lists one time during initialization, it not only fixes the list corruption, but also avoids INITLISTHEAD() redundantly.
V2: change "int i" to "unsigned int i" (Geert Uytterhoeven)
In the Linux kernel, the following vulnerability has been resolved:
iio: buffer: Fix file related error handling in IIOBUFFERGETFDIOCTL
If we fail to copy the just created file descriptor to userland, we try to clean up by putting back 'fd' and freeing 'ib'. The code uses putunusedfd() for the former which is wrong, as the file descriptor was already published by fdinstall() which gets called internally by anoninodegetfd().
This makes the error handling code leaving a half cleaned up file descriptor table around and a partially destructed 'file' object, allowing userland to play use-after-free tricks on us, by abusing the still usable fd and making the code operate on a dangling 'file->privatedata' pointer.
Instead of leaving the kernel in a partially corrupted state, don't attempt to explicitly clean up and leave this to the process exit path that'll release any still valid fds, including the one created by the previous call to anoninodegetfd(). Simply return -EFAULT to indicate the error.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: max9759: fix underflow in speakergaincontrolput()
Check for negative values of "priv->gain" to prevent an out of bounds access. The concern is that these might come from the user via: -> sndctlelemwriteuser() -> sndctlelemwrite() -> kctl->put()
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Zap all roots when unmapping gfn range in TDP MMU
Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn't zap invalid roots in mmunotifier callbacks. This leads to use-after-free and other issues if the mmunotifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be no references to the page after the mmunotifier returns.
The bug is most easily reproduced by hacking KVM to cause a collision between setnxhugepages() and kvmmmunotifierrelease(), but the bug exists between kvmmmunotifierinvalidaterangestart() and memslot updates as well. Invalidating a root ensures pages aren't accessible by the guest, and KVM won't read or write page data itself, but KVM will trigger e.g. kvmsetpfndirty() when zapping SPTEs, and thus completing a zap of an invalid root after the mmunotifier returns is fatal.
WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvmmain.c:173 [kvm] RIP: 0010:kvmiszonedevicepfn+0x96/0xa0 [kvm] Call Trace: <TASK> kvmsetpfndirty+0xa8/0xe0 [kvm] handlechangedspte+0x2ab/0x5e0 [kvm] handlechangedspte+0x2ab/0x5e0 [kvm] handlechangedspte+0x2ab/0x5e0 [kvm] zapgfnrange+0x1f3/0x310 [kvm] kvmtdpmmuzapinvalidatedroots+0x50/0x90 [kvm] kvmmmuzapallfast+0x177/0x1a0 [kvm] setnxhugepages+0xb4/0x190 [kvm] paramattrstore+0x70/0x100 moduleattrstore+0x19/0x30 kernfsfopwriteiter+0x119/0x1b0 newsyncwrite+0x11c/0x1b0 vfswrite+0x1cc/0x270 ksyswrite+0x5f/0xe0 dosyscall64+0x38/0xc0 entrySYSCALL64afterhwframe+0x44/0xae </TASK>
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Ensure rdmaaddrcancel() happens before issuing more requests
The FSM can run in a circle allowing rdmaresolveip() to be called twice on the same idpriv. While this cannot happen without going through the work, it violates the invariant that the same address resolution background request cannot be active twice.
CPU 1 CPU 2
rdmaresolveaddr(): RDMACMIDLE -> RDMACMADDRQUERY rdmaresolveip(addrhandler) #1
processonereq(): for #1 addrhandler(): RDMACMADDRQUERY -> RDMACMADDRBOUND mutexunlock(&idpriv->handlermutex); [.. handler still running ..]
rdmaresolveaddr(): RDMACMADDRBOUND -> RDMACMADDRQUERY rdmaresolveip(addrhandler) !! two requests are now on the reqlist
rdmadestroyid(): destroyidhandlerunlock(): destroyid(): cmacanceloperation(): rdmaaddrcancel()
// processonereq() self removes it spinlockbh(&lock); canceldelayedwork(&req->work); if (!listempty(&req->list)) == true
! rdmaaddrcancel() returns after processonreq #1 is done
kfree(idpriv)
processonereq(): for #2 addrhandler(): mutexlock(&idpriv->handlermutex); !! Use after free on idpriv
rdmaaddrcancel() expects there to be one req on the list and only cancels the first one. The self-removal behavior of the work only happens after the handler has returned. This yields a situations where the reqlist can have two reqs for the same "handle" but rdmaaddrcancel() only cancels the first one.
The second req remains active beyond rdmadestroyid() and will use-after-free idpriv once it inevitably triggers.
Fix this by remembering if the idpriv has called rdmaresolveip() and always cancel before calling it again. This ensures the reqlist never gets more than one item in it and doesn't cost anything in the normal flow that never uses this strange error path.