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:
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:
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:
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:
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:
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:
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:
netfilter: nfconntrackh323: Add protection for bmp length out of range
The Linux kernel CVE team has assigned CVE-2024-26851 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041723-CVE-2024-26851-4652@gregkh/T
igc: avoid returning frame twice in XDPREDIRECT
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:
nfsd: fix RELEASELOCKOWNER
The Linux kernel CVE team has assigned CVE-2024-26629 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/20240313140155.1913910-4-lee@kernel.org/T
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:
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:
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:
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:
tomoyo: fix UAF write bug in tomoyowritecontrol()
Since tomoyowritecontrol() updates head->writebuf when write() of long lines is requested, we need to fetch head->writebuf after head->iosem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems.
In the Linux kernel, the following vulnerability has been resolved:
pdscore: Prevent race issues involving the adminq
There are multiple paths that can result in using the pdsc's adminq.
[1] pdscadminqisr and the resulting work from queuework(), i.e. pdscworkthread()->pdscprocessadminq()
[2] pdscadminqpost()
When the device goes through reset via PCIe reset and/or a fwdown/fwup cycle due to bad PCIe state or bad device state the adminq is destroyed and recreated.
A NULL pointer dereference can happen if [1] or [2] happens after the adminq is already destroyed.
In order to fix this, add some further state checks and implement reference counting for adminq uses. Reference counting was used because multiple threads can attempt to access the adminq at the same time via [1] or [2]. Additionally, multiple clients (i.e. pds-vfio-pci) can be using [2] at the same time.
The adminqrefcnt is initialized to 1 when the adminq has been allocated and is ready to use. Users/clients of the adminq (i.e. [1] and [2]) will increment the refcnt when they are using the adminq. When the driver goes into a fwdown cycle it will set the PDSCSFWDEAD bit and then wait for the adminqrefcnt to hit 1. Setting the PDSCSFWDEAD before waiting will prevent any further adminqrefcnt increments. Waiting for the adminqrefcnt to hit 1 allows for any current users of the adminq to finish before the driver frees the adminq. Once the adminqrefcnt hits 1 the driver clears the refcnt to signify that the adminq is deleted and cannot be used. On the fwup cycle the driver will once again initialize the adminqrefcnt to 1 allowing the adminq to be used again.
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: rely on mac80211 debugfs handling for vif
mac80211 started to delete debugfs entries in certain cases, causing a ath11k to crash when it tried to delete the entries later. Fix this by relying on mac80211 to delete the entries when appropriate and adding them from the vifadddebugfs handler.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix RCU use in TDLS fast-xmit
This looks up the link under RCU protection, but isn't guaranteed to actually have protection. Fix that.
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Fix out-of-bounds memory access
Fix a bug that pdata->cpumap[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix array-index-out-of-bounds in dcn35clkmgr
[Why] There is a potential memory access violation while iterating through array of dcn35 clks.
[How] Limit iteration per array size.
In the Linux kernel, the following vulnerability has been resolved:
lan966x: Fix crash when adding interface under a lag
There is a crash when adding one of the lan966x interfaces under a lag interface. The issue can be reproduced like this: ip link add name bond0 type bond miimon 100 mode balance-xor ip link set dev eth0 master bond0
The reason is because when adding a interface under the lag it would go through all the ports and try to figure out which other ports are under that lag interface. And the issue is that lan966x can have ports that are NULL pointer as they are not probed. So then iterating over these ports it would just crash as they are NULL pointers. The fix consists in actually checking for NULL pointers before accessing something from the ports. Like we do in other places.