In the Linux kernel before 6.6.7, an untrusted VMM can trigger int80 syscall handling at any given point. This is related to arch/x86/coco/tdx/tdx.c and arch/x86/mm/memencryptamd.c.
In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
hidppconnectevent() has four time-of-check vs time-of-use (TOCTOU) races when it races with itself.
hidppconnectevent() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidppconnectevent() from probe() is waiting on the hw, then a second thread running hidppconnectevent() will be started from the workqueue.
This opens the following races (note the below code is simplified):
1. Retrieving + printing the protocol (harmless race):
if (!hidpp->protocolmajor) { hidpprootgetprotocolversion() hidpp->protocolmajor = response.rap.params[0]; }
We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968:
[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (sendmutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them:
2. Updating the name to the HIDPP name (harmless race):
if (hidpp->name == hdev->name) { ... hidpp->name = newname; }
3. Initializing the powersupply class for the battery (problematic!):
hidppinitializebattery() { if (hidpp->battery.ps) return 0;
probebattery(); / Blocks, threads take turns executing this /
hidpp->battery.desc.properties = devmkmemdup(dev, hidppbatteryprops, cnt, GFPKERNEL);
hidpp->battery.ps = devmpowersupplyregister(&hidpp->hiddev->dev, &hidpp->battery.desc, cfg); }
4. Creating delayed inputdevice (potentially problematic):
if (hidpp->delayedinput) return;
hidpp->delayedinput = hidppallocateinput(hdev);
The really big problem here is 3. Hitting the race leads to the following sequence:
hidpp->battery.desc.properties = devmkmemdup(dev, hidppbatteryprops, cnt, GFPKERNEL);
hidpp->battery.ps = devmpowersupplyregister(&hidpp->hiddev->dev, &hidpp->battery.desc, cfg);
...
hidpp->battery.desc.properties = devmkmemdup(dev, hidppbatteryprops, cnt, GFPKERNEL);
hidpp->battery.ps = devmpowersupplyregister(&hidpp->hiddev->dev, &hidpp->battery.desc, cfg);
So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem.
Notice how:
1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devmkmemdup()
This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devmkmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes powersupplyuevent() to fill the uevent data 4. powersupplyuevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one:
Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usbhubwq hubevent Sep 22 20:01:35 eric kernel: RIP: 0010:powersupplyuevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asmexcpagefault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? powersupplyuevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? powersupplyuevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: devuevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobjectueventenv+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix potential key use-after-free
The Linux kernel CVE team has assigned CVE-2023-52530 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024030255-CVE-2023-52530-ebf0@gregkh/T/#u
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:
swiotlb: Fix double-allocation of slots due to broken alignment handling
Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"), which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment checks"), causes a functional regression with vsock in a virtual machine using bouncing via a restricted DMA SWIOTLB pool.
When virtio allocates the virtqueues for the vsock device using dmaalloccoherent(), the SWIOTLB search can return page-unaligned allocations if 'area->index' was left unaligned by a previous allocation from the buffer:
# Final address in brackets is the SWIOTLB address returned to the caller | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800)
This ends badly (typically buffer corruption and/or a hang) because swiotlballoc() is expecting a page-aligned allocation and so blindly returns a pointer to the 'struct page' corresponding to the allocation, therefore double-allocating the first half (2KiB slot) of the 4KiB page.
Fix the problem by treating the allocation alignment separately to any additional alignment requirements from the device, using the maximum of the two as the stride to search the buffer slots and taking care to ensure a minimum of page-alignment for buffers larger than a page.
This also resolves swiotlb allocation failures occuring due to the inclusion of ~PAGEMASK in 'iotlbalignmask' for large allocations and resulting in alignment requirements exceeding swiotlbmaxmappingsize().
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrumacltcam: Fix possible use-after-free during rehash
The Linux kernel CVE team has assigned CVE-2024-35854 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35854-d17b@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: guard against invalid STA ID on removal
Guard against invalid station IDs in iwlmvmmldrmstaid as that would result in out-of-bounds array accesses. This prevents issues should the driver get into a bad state during error handling.
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: Lock wiphy in cfg80211getstation
Wiphy should be locked before calling rdevgetstation() (see lockdep assert in ieee80211getstation()).
This fixes the following kernel NULL dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3mesong12a dwc3ofsimple dwc3 ipgre gre ath10kpci ath10kcore ath9k ath9kcommon ath9khw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: batevents batadvvelpthroughputmetricupdate pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10kstastatistics+0x10/0x2dc [ath10kcore] lr : stasetsinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10kstastatistics+0x10/0x2dc [ath10kcore] stasetsinfo+0xcc/0xbd4 ieee80211getstation+0x2c/0x44 cfg80211getstation+0x80/0x154 batadvvelpgetthroughput+0x138/0x1fc batadvvelpthroughputmetricupdate+0x1c/0xa4 processonework+0x1ec/0x414 workerthread+0x70/0x46c kthread+0xdc/0xe0 retfromfork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)
This happens because STA has time to disconnect and reconnect before batadvvelpthroughputmetricupdate() delayed work gets scheduled. In this situation, ath10kstastate() can be in the middle of resetting arsta data when the work queue get chance to be scheduled and ends up accessing it. Locking wiphy prevents that.
A denial-of-service (DoS) attack was found in the mlx5 driver in the Linux kernel. A KVM guest VM using virtio-net can crash the host by sending a short packet (i.e. size < ETHHLEN). The packet may traverse through vhost-net, macvtap and vlan without any validation/drop. When this packet is presented to mlx5 driver on the host side, the kernel panic happens, since mlx5core assumes the frame size is always >= ETHHLEN.
This vulnerability affects both drivers/net/tun.c and drivers/net/tap.c. CVE-2024-41090 has been assigned to the TAP side of the issue.
Reference: https://www.openwall.com/lists/oss-security/2024/07/24/4
A denial-of-service (DoS) attack was found in the mlx5 driver in the Linux kernel. A KVM guest VM using virtio-net can crash the host by sending a short packet (i.e. size < ETHHLEN). The packet may traverse through vhost-net, macvtap and vlan without any validation/drop. When this packet is presented to mlx5 driver on the host side, the kernel panic happens since mlx5core assumes the frame size is always >= ETHHLEN.
This vulnerability affects both drivers/net/tun.c and drivers/net/tap.c. CVE-2024-41091 has been assigned to the TUN side of the issue.
Reference: https://www.openwall.com/lists/oss-security/2024/07/24/4
A flaw was found in in LibTIFF 4.0.9. ChopUpSingleUncompressedStrip in tifdirread.c allows remote attackers to cause a denial of service (heap-based buffer overflow and application crash) via a crafted TIFF file, as demonstrated by tiff2pdf.
References: http://bugzilla.maptools.org/showbug.cgi?id=2808
In the Linux kernel, the following vulnerability has been resolved:
virtio-net: Add validation for used length
The Linux kernel CVE team has assigned CVE-2021-47352 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052141-CVE-2021-47352-df50@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
can: peakpci: peakpciremove(): fix UAF
The Linux kernel CVE team has assigned CVE-2021-47456 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052244-CVE-2021-47456-dc47@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
phylib: fix potential use-after-free
Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call to phydevicereset(phydev) after the putdevice() call in phydetach().
The comment before the putdevice() call says that the phydev might go away with putdevice().
Fix potential use-after-free by calling phydevicereset() before putdevice().
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: replace skbput with skbputzero
Avoid potentially reusing uninitialized data
In the Linux kernel, the following vulnerability has been resolved:
crypto: s390/aes - Fix buffer overread in CTR mode
The Linux kernel CVE team has assigned CVE-2023-52669 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051728-CVE-2023-52669-5a58@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
net/smc: avoid data corruption caused by decline
The Linux kernel CVE team has assigned CVE-2023-52775 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052151-CVE-2023-52775-38a8@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential OOBs in smb2parsecontexts()
Validate offsets and lengths before dereferencing create contexts in smb2parsecontexts().
This fixes following oops when accessing invalid create contexts from server:
BUG: unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2parsecontexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP: 0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? die+0x23/0x70 ? pagefaultoops+0x181/0x480 ? searchmoduleextables+0x19/0x60 ? srsoaliasreturnthunk+0x5/0xfbef5 ? excpagefault+0x1b6/0x1c0 ? asmexcpagefault+0x26/0x30 ? smb2parsecontexts+0xa0/0x3a0 [cifs] SMB2open+0x38d/0x5f0 [cifs] ? smb2ispathaccessible+0x138/0x260 [cifs] smb2ispathaccessible+0x138/0x260 [cifs] cifsispathremote+0x8d/0x230 [cifs] cifsmount+0x7e/0x350 [cifs] cifssmb3domount+0x128/0x780 [cifs] smb3gettree+0xd9/0x290 [cifs] vfsgettree+0x2c/0x100 ? capable+0x37/0x70 pathmount+0x2d7/0xb80 ? srsoaliasreturnthunk+0x5/0xfbef5 ? rawspinunlockirqrestore+0x44/0x60 x64sysmount+0x11a/0x150 dosyscall64+0x47/0xf0 entrySYSCALL64afterhwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: check A-MSDU format more carefully
If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.
In the Linux kernel, the following vulnerability has been resolved:
net: amd-xgbe: Fix skb data length underflow
The Linux kernel CVE team has assigned CVE-2022-48743 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024062003-CVE-2022-48743-ee30@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't read past the mfuart notifcation
In case the firmware sends a notification that claims it has more data than it has, we will read past that was allocated for the notification. Remove the print of the buffer, we won't see it by default. If needed, we can see the content with tracing.
This was reported by KFENCE.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
The Linux kernel CVE team has assigned CVE-2024-35789 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051707-CVE-2024-35789-52e5@gregkh/T
An integer wraparound in the function l2capconfigreq in net/bluetooth/l2capcore.c in Linux Kernel could allow a remote authenticated attacker from within the local network using L2CAPCONFREQ packets to cause an unknown impact.
An out-of-bounds access vulnerability involving netfilter was reported and fixed as: f1082dd31fe4 (netfilter: nftables: Reject tables of unsupported family)
A flaw was found in unrestricted eBPF usage by the BPFBTFLOAD, leading to a possible out-of-bounds memory write in the Linux kernel’s BPF subsystem due to the way a user loads BTF. This flaw allows a local user to crash or escalate their privileges on the system.
Integer overflow in raid5cachecount in Linux kernel
A flaw in the Linux Kernel found. Null pointer dereference in hugetlbfsfillsuper function for hugetlbfs (HugeTLB pages). The issue presents when we attempt to update the pagesize value to an invalid size with the fsconfig syscall. This syscall will eventually call hugetlbfsparseparam() where we will set the hstate value to null if the value passed is not a valid page size. If we then attempt to update the fs again with a fsconfig syscall, specifically with the FSCONFIGCMDCREATE option, we will then attempt to dereference that null pointer within hugetlbfsfillsuper() causing a panic.
kernel/bpf/verifier.c in the Linux kernel through 5.15.14 allows local users to gain privileges because of the availability of pointer arithmetic via certain ORNULL pointer types.
In the Linux kernel, the following vulnerability has been resolved:
uio: Fix use-after-free in uioopen
core-1 core-2 ------------------------------------------------------- uiounregisterdevice uioopen idev = idrfind() deviceunregister(&idev->dev) putdevice(&idev->dev) uiodevicerelease getdevice(&idev->dev) kfree(idev) uiofreeminor(minor) uiorelease putdevice(&idev->dev) kfree(idev) -------------------------------------------------------
In the core-1 uiounregisterdevice(), the deviceunregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 deviceunregister, putdevice and before doing kfree, the core-2 may getdevice. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uiorelease and putdevice, the idev will be double freed.
To address this issue, we can get idev atomic & inc idev reference with minorlock.