In the Linux kernel, the following vulnerability has been resolved:
scsi: target: pscsi: Fix bioput() for error case
As of commit 066ff571011d ("block: turn biokmalloc into a simple kmalloc wrapper"), a bio allocated by biokmalloc() must be freed by biouninit() and kfree(). That is not done properly for the error case, hitting WARN and NULL pointer dereference in biofree().
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix double-free on socket dismantle
The Linux kernel CVE team has assigned CVE-2024-26782 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040458-CVE-2024-26782-71ca@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
tls: fix use-after-free on failed backlog decryption
When the decrypt request goes to the backlog and cryptoaeaddecrypt returns -EBUSY, tlsdodecryption will wait until all async decryptions have completed. If one of them fails, tlsdodecryption will return -EBADMSG and tlsdecryptsg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tlsdecryptdone.
The only true async case is when cryptoaeaddecrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tlsswrecvmsg that the data is available for immediate copy, but we need to notify tlsdecryptsg (via the new ->asyncdone flag) that the memory has already been released.
In the Linux kernel, the following vulnerability has been resolved:
igc: avoid returning frame twice in XDPREDIRECT
The Linux kernel CVE team has assigned CVE-2024-26853 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041723-CVE-2024-26853-b549@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
tls: separate no-async decryption request handling from async
If we're not doing async, the handling is much simpler. There's no reference counting, we just need to wait for the completion to wake us up and return its result.
We should preferably also use a separate cryptowait. I'm not seeing a UAF as I did in the past, I think aec7961916f3 ("tls: fix race between async notify and socket close") took care of it.
This will make the next fix easier.
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix underflow in parseserverinterfaces()
In this loop, we step through the buffer and after each item we check if the sizeleft is greater than the minimum size we need. However, the problem is that "bytesleft" is type ssizet while sizeof() is type sizet. That means that because of type promotion, the comparison is done as an unsigned and if we have negative bytes left the loop continues instead of ending.
In the Linux kernel, the following vulnerability has been resolved:
tunnels: fix out of bounds access when building IPv6 PMTU error
If the ICMPv6 error is built from a non-linear skb we get the following splat,
BUG: KASAN: slab-out-of-bounds in docsum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasanreport+0xd8/0x110 docsum+0x220/0x240 csumpartial+0xc/0x20 skbtunnelcheckpmtu+0xeb9/0x3280 vxlanxmitone+0x14c2/0x4080 vxlanxmit+0xf61/0x5c00 devhardstartxmit+0xfb/0x510 devqueuexmit+0x7cd/0x32a0 brdevqueuepushxmit+0x39d/0x6a0
Use skbchecksum instead of csumpartial who cannot deal with non-linear SKBs.
In the Linux kernel, the following vulnerability has been resolved:
ceph: prevent use-after-free in encodecapmsg()
In fs/ceph/caps.c, in encodecapmsg(), "use after free" error was caught by KASAN at this line - 'cephbufferget(arg->xattrbuf);'. This implies before the refcount could be increment here, it was freed.
In same file, in "handlecapgrant()" refcount is decremented by this line - 'cephbufferput(ci->ixattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it.
encodecapmsg() is called by sendcap() and sendcap() is called by cephcheckcaps() after calling prepcap(). prepcap() is where arg->xattrbuf is assigned to ci->ixattrs.blob. This is the spot where the refcount must be increased to prevent "use after free" error.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix race condition on enabling fast-xmit
fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise it could end up passing the not-yet-uploaded sta via drvtx calls to the driver, leading to potential crashes because of uninitialized drvpriv data. Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Avoid potential use-after-free in hcierrorreset
The Linux kernel CVE team has assigned CVE-2024-26801 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040403-CVE-2024-26801-da9f@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
net: sparx5: Fix use after free inside sparx5delmactentry
Based on the static analyzis of the code it looks like when an entry from the MAC table was removed, the entry was still used after being freed. More precise the vid of the macentry was used after calling devmkfree on the macentry. The fix consists in first using the vid of the macentry to delete the entry from the HW and after that to free it.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hcievent: Fix handling of HCIEVIOCAPAREQUEST
If we received HCIEVIOCAPAREQUEST while HCIOPREADREMOTEEXTFEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: confirm multicast packets before passing them up the stack
conntrack nfconfirm logic cannot handle cloned skbs referencing the same nfconn entry, which will happen for multicast (broadcast) frames on bridges.
Example: macvlan0 | br0 / \ ethX ethY
ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table.
1. skb passes through bridge and fake-ip (brnetfilter)Prerouting. -> skb->nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices.
The clone skb->nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RXHANDLERPASS. 5. Normal conntrack hooks (in NFINETLOCALIN) confirm the orig skb.
The Macvlan broadcast worker and normal confirm path will race.
This race will not happen if step 2 already confirmed a clone. In that case later steps perform skbclone() with skb->nfct already confirmed (in hash table). This works fine.
But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nfconfirm step in postrouting.
Pablo points out that nfconntrackbridge doesn't allow use of stateful nat, so we can safely discard the nfconn entry and let inet call conntrack again.
This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotagein' hook.
Work around this problem by explicit confirmation of the entry at LOCALIN time, before upper layer has a chance to clone the unconfirmed entry.
The downside is that this disables NAT and conntrack helpers.
Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example:
-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5
For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings.
Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Mark target gfn of emulated atomic instruction as dirty
When emulating an atomic access on behalf of the guest, mark the target gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This fixes a bug where KVM effectively corrupts guest memory during live migration by writing to guest memory without informing userspace that the page is dirty.
Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user access. Before that, KVM explicitly mapped the guest page into kernel memory, and marked the page dirty during the unmap phase.
Mark the page dirty even if the CMPXCHG fails, as the old data is written back on failure, i.e. the page is still written. The value written is guaranteed to be the same because the operation is atomic, but KVM's ABI is that all writes are dirty logged regardless of the value written. And more importantly, that's what KVM did before the buggy commit.
Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and debugging.
base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64
In the Linux kernel, the following vulnerability has been resolved:
smb: client: set correct id, uid and cruid for multiuser automounts
When uid, gid and cruid are not specified, we need to dynamically set them into the filesystem context used for automounting otherwise they'll end up reusing the values from the parent mount.
In the Linux kernel, the following vulnerability has been resolved:
ip6tunnel: make sure to pull inner header in ip6tnlrcv()
syzbot found ip6tnlrcv() could access unitiliazed data [1].
Call pskbinetmaypull() to fix this, and initialize ipv6h variable after this call as it can change skb->head.
[1] BUG: KMSAN: uninit-value in INETECNdecapsulate include/net/inetecn.h:253 [inline] BUG: KMSAN: uninit-value in INETECNdecapsulate include/net/inetecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6ECNdecapsulate+0x7df/0x1e50 include/net/inetecn.h:321 INETECNdecapsulate include/net/inetecn.h:253 [inline] INETECNdecapsulate include/net/inetecn.h:275 [inline] IP6ECNdecapsulate+0x7df/0x1e50 include/net/inetecn.h:321 ip6ip6dscpecndecapsulate+0x178/0x1b0 net/ipv6/ip6tunnel.c:727 ip6tnlrcv+0xd4e/0x1590 net/ipv6/ip6tunnel.c:845 ip6tnlrcv+0xce/0x100 net/ipv6/ip6tunnel.c:888 grercv+0x143f/0x1870 ip6protocoldeliverrcu+0xda6/0x2a60 net/ipv6/ip6input.c:438 ip6inputfinish net/ipv6/ip6input.c:483 [inline] NFHOOK include/linux/netfilter.h:314 [inline] ip6input+0x15d/0x430 net/ipv6/ip6input.c:492 ip6mcinput+0xa7e/0xc80 net/ipv6/ip6input.c:586 dstinput include/net/dst.h:461 [inline] ip6rcvfinish+0x5db/0x870 net/ipv6/ip6input.c:79 NFHOOK include/linux/netfilter.h:314 [inline] ipv6rcv+0xda/0x390 net/ipv6/ip6input.c:310 netifreceiveskbonecore net/core/dev.c:5532 [inline] netifreceiveskb+0x1a6/0x5a0 net/core/dev.c:5646 netifreceiveskbinternal net/core/dev.c:5732 [inline] netifreceiveskb+0x58/0x660 net/core/dev.c:5791 tunrxbatched+0x3ee/0x980 drivers/net/tun.c:1555 tungetuser+0x53af/0x66d0 drivers/net/tun.c:2002 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2084 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x786/0x1200 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 dosyswrite fs/readwrite.c:655 [inline] sesyswrite fs/readwrite.c:652 [inline] x64syswrite+0x93/0xd0 fs/readwrite.c:652 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5e9/0xb10 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 allocskb+0x318/0x740 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1286 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6334 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2787 tunallocskb drivers/net/tun.c:1531 [inline] tungetuser+0x1e8a/0x66d0 drivers/net/tun.c:1846 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2084 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x786/0x1200 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 dosyswrite fs/readwrite.c:655 [inline] sesyswrite fs/readwrite.c:652 [inline] x64syswrite+0x93/0xd0 fs/readwrite.c:652 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
i40e: Do not allow untrusted VF to remove administratively set MAC
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fixed overflow check in mienumattr()
In the Linux kernel, the following vulnerability has been resolved:
smb: Fix regression in writes when non-standard maximum write size negotiated
The conversion to netfs in the 6.3 kernel caused a regression when maximum write size is set by the server to an unexpected value which is not a multiple of 4096 (similarly if the user overrides the maximum write size by setting mount parm "wsize", but sets it to a value that is not a multiple of 4096). When negotiated write size is not a multiple of 4096 the netfs code can skip the end of the final page when doing large sequential writes, causing data corruption.
This section of code is being rewritten/removed due to a large netfs change, but until that point (ie for the 6.3 kernel until now) we can not support non-standard maximum write sizes.
Add a warning if a user specifies a wsize on mount that is not a multiple of 4096 (and round down), also add a change where we round down the maximum write size if the server negotiates a value that is not a multiple of 4096 (we also have to check to make sure that we do not round it down to zero).
In the Linux kernel, the following vulnerability has been resolved:
mm: hugememory: don't force huge page alignment on 32 bit
commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") caused two issues [1] [2] reported on 32 bit system or compat userspace.
It doesn't make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space.
[1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/
In the Linux kernel, the following vulnerability has been resolved:
libceph: just wait for more data to be available on the socket
A short read may occur while reading the message footer from the socket. Later, when the socket is ready for another read, the messenger invokes all readpartial() handlers, including readpartialsparsemsgdata(). The expectation is that readpartialsparsemsgdata() would bail, allowing the messenger to invoke readpartial() for the footer and pick up where it left off.
However readpartialsparsemsgdata() violates that and ends up calling into the state machine in the OSD client. The sparse-read state machine assumes that it's a new op and interprets some piece of the footer as the sparse-read header and returns bogus extents/data length, etc.
To determine whether readpartialsparsemsgdata() should bail, let's reuse cursor->totalresid. Because once it reaches to zero that means all the extents and data have been successfully received in last read, else it could break out when partially reading any of the extents and data. And then osdsparseread() could continue where it left off.
[ idryomov: changelog ]
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix data races on remoteid
Similar to the previous patch, address the data race on remoteid, adding the suitable ONCE annotations.
In the Linux kernel, the following vulnerability has been resolved:
xsk: recycle buffer in case Rx queue was full
Add missing xskbufffree() call when xskrcvzc() failed to produce descriptor to XSK Rx queue.
In the Linux kernel, the following vulnerability has been resolved:
tls: stop recv() if initial processrxlist gave us non-DATA
If we have a non-DATA record on the rxlist and another record of the same type still on the queue, we will end up merging them: - processrxlist copies the non-DATA record - we start the loop and process the first available record since it's of the same type - we break out of the loop since the record was not DATA
Just check the record type and jump to the end in case processrxlist did some work.
In the Linux kernel, the following vulnerability has been resolved:
afs: Increase buffer size in afsupdatevolumestatus()
The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()]
A use-after-free vulnerability in the Linux kernel's netfilter: nftables component can be exploited to achieve local privilege escalation.
The nftverdictinit() function allows positive values as drop error within the hook verdict, and hence the nfhookslow() function can cause a double free vulnerability when NFDROP is issued with a drop error which resembles NFACCEPT.
We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix global oob in ksmbdnlpolicy
Similar to a reported issue (check the commit b33fb5b801c6 ("net: qualcomm: rmnet: fix global oob in rmnetpolicy"), my local fuzzer finds another global out-of-bounds read for policy ksmbdnlpolicy. See bug trace below:
================================================================== BUG: KASAN: global-out-of-bounds in validatenla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in nlavalidateparse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810
CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x8b/0xb3 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:284 [inline] printreport+0x172/0x475 mm/kasan/report.c:395 kasanreport+0xbb/0x1c0 mm/kasan/report.c:495 validatenla lib/nlattr.c:386 [inline] nlavalidateparse+0x24af/0x2750 lib/nlattr.c:600 nlaparse+0x3e/0x50 lib/nlattr.c:697 nlmsgparse include/net/netlink.h:748 [inline] genlfamilyrcvmsgattrsparse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565 genlfamilyrcvmsgdoit+0xda/0x330 net/netlink/genetlink.c:734 genlfamilyrcvmsg net/netlink/genetlink.c:833 [inline] genlrcvmsg+0x441/0x780 net/netlink/genetlink.c:850 netlinkrcvskb+0x14f/0x410 net/netlink/afnetlink.c:2540 genlrcv+0x24/0x40 net/netlink/genetlink.c:861 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0x54e/0x800 net/netlink/afnetlink.c:1345 netlinksendmsg+0x930/0xe50 net/netlink/afnetlink.c:1921 socksendmsgnosec net/socket.c:714 [inline] socksendmsg+0x154/0x190 net/socket.c:734 syssendmsg+0x6df/0x840 net/socket.c:2482 syssendmsg+0x110/0x1b0 net/socket.c:2536 syssendmsg+0xf3/0x1c0 net/socket.c:2565 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3b/0x90 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7fdd66a8f359 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:00007fdd65e00168 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003 RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000 </TASK>
The buggy address belongs to the variable: ksmbdnlpolicy+0x100/0xa80
The buggy address belongs to the physical page: page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9 ^ ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05 ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9 ==================================================================
To fix it, add a placeholder named KSMBDEVENTMAX and let KSMBDEVENTMAX to be its original value - 1 according to what other netlink families do. Also change two sites that refer the KSMBDEVENTMAX to correct value.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: scrub: avoid use-after-free when chunk length is not 64K aligned
[BUG] There is a bug report that, on a ext4-converted btrfs, scrub leads to various problems, including:
- "unable to find chunk map" errors BTRFS info (device vdb): scrub: started on devid 1 BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096 BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056
This would lead to unrepariable errors.
- Use-after-free KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in blkrqmapsg+0x18f/0x7c0 Read of size 8 at addr ffff8881013c9040 by task btrfs/909 CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2023.11-2 12/24/2023 Call Trace: <TASK> dumpstacklvl+0x43/0x60 printreport+0xcf/0x640 kasanreport+0xa6/0xd0 blkrqmapsg+0x18f/0x7c0 virtblkpreprq.isra.0+0x215/0x6a0 [virtioblk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff] virtioqueuerqs+0xc4/0x310 [virtioblk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff] blkmqflushpluglist.part.0+0x780/0x860 blkflushplug+0x1ba/0x220 blkfinishplug+0x3b/0x60 submitinitialgroupread+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] flushscrubstripes+0x38e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] scrubstripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] scrubchunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] scrubenumeratechunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btrfsscrubdev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btrfsioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] x64sysioctl+0xbd/0x100 dosyscall64+0x5d/0xe0 entrySYSCALL64afterhwframe+0x63/0x6b RIP: 0033:0x7f47e5e0952b
- Crash, mostly due to above use-after-free
[CAUSE] The converted fs has the following data chunk layout:
item 2 key (FIRSTCHUNKTREE CHUNKITEM 2214658048) itemoff 16025 itemsize 80 length 86016 owner 2 stripelen 65536 type DATA|single
For above logical bytenr 2214744064, it's at the chunk end (2214658048 + 86016 = 2214744064).
This means btrfssubmitbio() would split the bio, and trigger endio function for both of the two halves.
However scrubsubmitinitialread() would only expect the endio function to be called once, not any more. This means the first endio function would already free the bbio::bio, leaving the bvec freed, thus the 2nd endio call would lead to use-after-free.
[FIX] - Make sure scrubreadendio() only updates bits in its range Since we may read less than 64K at the end of the chunk, we should not touch the bits beyond chunk boundary.
- Make sure scrubsubmitinitialread() only to read the chunk range This is done by calculating the real number of sectors we need to read, and add sector-by-sector to the bio.
Thankfully the scrub read repair path won't need extra fixes:
- scrubstripesubmitrepairread() With above fixes, we won't update error bit for range beyond chunk, thus scrubstripesubmitrepairread() should never submit any read beyond the chunk.
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: fix a memory corruption
iwlfwinitriggertlv::data is a pointer to a le32, which means that if we copy to iwlfwinitriggertlv::data + offset while offset is in bytes, we'll write past the buffer.
In the Linux kernel, the following vulnerability has been resolved:
tcp: make sure init the acceptqueue's spinlocks once
When I run syz's reproduction C program locally, it causes the following issue: pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at pvqueuedspinunlockslowpath (kernel/locking/qspinlockparavirt.h:508) Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:pvqueuedspinunlockslowpath (kernel/locking/qspinlockparavirt.h:508) Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace:
rawspinunlock (kernel/locking/spinlock.c:186) inetcskreqskqueueadd (net/ipv4/inetconnectionsock.c:1321) inetcskcompletehashdance (net/ipv4/inetconnectionsock.c:1358) tcpcheckreq (net/ipv4/tcpminisocks.c:868) tcpv4rcv (net/ipv4/tcpipv4.c:2260) ipprotocoldeliverrcu (net/ipv4/ipinput.c:205) iplocaldeliverfinish (net/ipv4/ipinput.c:234) netifreceiveskbonecore (net/core/dev.c:5529) processbacklog (./include/linux/rcupdate.h:779) napipoll (net/core/dev.c:6533) netrxaction (net/core/dev.c:6604) dosoftirq (./arch/x86/include/asm/jumplabel.h:27) dosoftirq (kernel/softirq.c:454 kernel/softirq.c:441)
localbhenableip (kernel/softirq.c:381) devqueuexmit (net/core/dev.c:4374) ipfinishoutput2 (./include/net/neighbour.h:540 net/ipv4/ipoutput.c:235) ipqueuexmit (net/ipv4/ipoutput.c:535) tcptransmitskb (net/ipv4/tcpoutput.c:1462) tcprcvsynsentstateprocess (net/ipv4/tcpinput.c:6469) tcprcvstateprocess (net/ipv4/tcpinput.c:6657) tcpv4dorcv (net/ipv4/tcpipv4.c:1929) releasesock (./include/net/sock.h:1121 net/core/sock.c:2968) releasesock (net/core/sock.c:3536) inetwaitforconnect (net/ipv4/afinet.c:609) inetstreamconnect (net/ipv4/afinet.c:702) inetstreamconnect (net/ipv4/afinet.c:748) sysconnect (./include/linux/file.h:45 net/socket.c:2064) x64sysconnect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) dosyscall64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:129) RIP: 0033:0x7fa10ff05a3d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
The issue triggering process is analyzed as follows: Thread A Thread B tcpv4rcv //receive ack TCP packet inetshutdown tcpcheckreq tcpdisconnect //disconnect sock ... tcpsetstate(sk, TCPCLOSE) inetcskcompletehashdance ... inetcskreqskqueueadd ---truncated---