In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: ensure offloading TID queue exists
The Linux kernel CVE team has assigned CVE-2024-27056 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050115-CVE-2024-27056-98c0@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
loop: implement ->freedisk
Ensure that the lodevice which is stored in the gendisk private data is valid until the gendisk is freed. Currently the loop driver uses a lot of effort to make sure a device is not freed when it is still in use, but to to fix a potential deadlock this will be relaxed a bit soon.
In the Linux kernel, the following vulnerability has been resolved:
xfrm: Duplicate SPI Handling
The issue originates when Strongswan initiates an XFRMMSGALLOCSPI Netlink message, which triggers the kernel function xfrmallocspi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses.
This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops.
According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol.
Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spimin = 0x10000000 spimax = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable.
Current implementation: xfrmspihash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlistforeachentryrcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI
Proposed Change: xfrmstatelookupspiproto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: E-Switch, pair only capable devices
OFFLOADS paring using devcom is possible only on devices that support LAG. Filter based on lag capabilities.
This fixes an issue where mlx5getnextphysdev() was called without holding the interface lock.
This issue was found when commit bc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices") added an assert that verifies the interface lock is held.
WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5getnextphysdev+0xd2/0x100 [mlx5core] Modules linked in: mlx5vdpa vringh vhostiotlb vdpa mlx5ib mlx5core xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xtaddrtype iptablenat nfnat brnetfilter rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi rdmacm iwcm ibumad ibipoib ibcm ibuverbs ibcore overlay fuse [last unloaded: mlx5core] CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5getnextphysdev+0xd2/0x100 [mlx5core] Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff RSP: 0018:ffff88811bf47458 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001 RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78 RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437 R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000 R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428 FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> mlx5eswoffloadsdevcomevent+0x99/0x3b0 [mlx5core] mlx5devcomsendevent+0x167/0x1d0 [mlx5core] eswoffloadsenable+0x1153/0x1500 [mlx5core] ? mlx5eswoffloadscontrollervalid+0x170/0x170 [mlx5core] ? waitforcompletioniotimeout+0x20/0x20 ? mlx5rescandriverslocked+0x318/0x810 [mlx5core] mlx5eswitchenablelocked+0x586/0xc50 [mlx5core] ? mlx5eswitchdisablepfvfvports+0x1d0/0x1d0 [mlx5core] ? mlx5eswtrylock+0x1b/0xb0 [mlx5core] ? mlx5eswitchenable+0x270/0x270 [mlx5core] ? debugfscreatefile+0x260/0x3e0 mlx5devlinkeswitchmodeset+0x27e/0x870 [mlx5core] ? mutexlockionested+0x12c0/0x12c0 ? eswoffloadsdisable+0x250/0x250 [mlx5core] ? devlinknlcmdtrapgetdumpit+0x470/0x470 ? rcureadlockschedheld+0x3f/0x70 devlinknlcmdeswitchsetdoit+0x217/0x620
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: host: Stop setting the ACPI companion
It is no longer needed. The sysdev pointer is now used when assigning the ACPI companions to the xHCI ports and USB devices.
Assigning the ACPI companion here resulted in the fwnode->secondary pointer to be replaced also for the parent dwc3 device since the primary fwnode (the ACPI companion) was shared. That was unintentional and it created potential side effects like resource leaks.
In the Linux kernel, the following vulnerability has been resolved:
x86/mce: Work around an erratum on fast string copy instructions
A rare kernel panic scenario can happen when the following conditions are met due to an erratum on fast string copy instructions:
1) An uncorrected error. 2) That error must be in first cache line of a page. 3) Kernel must execute pagecopy from the page immediately before that page.
The fast string copy instructions ("REP; MOVS") could consume an uncorrectable memory error in the cache line right after the desired region to copy and raise an MCE.
Bit 0 of MSRIA32MISCENABLE can be cleared to disable fast string copy and will avoid such spurious machine checks. However, that is less preferable due to the permanent performance impact. Considering memory poison is rare, it's desirable to keep fast string copy enabled until an MCE is seen.
Intel has confirmed the following: 1. The CPU erratum of fast string copy only applies to Skylake, Cascade Lake and Cooper Lake generations.
Directly return from the MCE handler: 2. Will result in complete execution of the "REP; MOVS" with no data loss or corruption. 3. Will not result in another MCE firing on the next poisoned cache line due to "REP; MOVS". 4. Will resume execution from a correct point in code. 5. Will result in the same instruction that triggered the MCE firing a second MCE immediately for any other software recoverable data fetch errors. 6. Is not safe without disabling the fast string copy, as the next fast string copy of the same buffer on the same CPU would result in a PANIC MCE.
This should mitigate the erratum completely with the only caveat that the fast string copy is disabled on the affected hyper thread thus performance degradation.
This is still better than the OS crashing on MCEs raised on an irrelevant process due to "REP; MOVS' accesses in a kernel context, e.g., copypage.
Injected errors on 1st cache line of 8 anonymous pages of process 'proc1' and observed MCE consumption from 'proc2' with no panic (directly returned).
Without the fix, the host panicked within a few minutes on a random 'proc2' process due to kernel access from copypage.
[ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ]
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Avoid field-overflowing memcpy()
In preparation for FORTIFYSOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields.
Use flexible arrays instead of zero-element arrays (which look like they are always overflowing) and split the cross-field memcpy() into two halves that can be appropriately bounds-checked by the compiler.
We were doing:
#define ETHHLEN 14 #define VLANHLEN 4 ... #define MLX5EXDPMININLINE (ETHHLEN + VLANHLEN) ... struct mlx5etxwqe wqe = mlx5wqcycgetwqe(wq, pi); ... struct mlx5wqeethseg eseg = &wqe->eth; struct mlx5wqedataseg dseg = wqe->data; ... memcpy(eseg->inlinehdr.start, xdptxd->data, MLX5EXDPMININLINE);
target is wqe->eth.inlinehdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlantci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering bytecount (4 bytes), lkey (4 bytes), and addr (8 bytes).
struct mlx5etxwqe { struct mlx5wqectrlseg ctrl; / 0 16 / struct mlx5wqeethseg eth; / 16 16 / struct mlx5wqedataseg data[]; / 32 0 /
/ size: 32, cachelines: 1, members: 3 / / last cacheline: 32 bytes / };
struct mlx5wqeethseg { u8 swpouterl4offset; / 0 1 / u8 swpouterl3offset; / 1 1 / u8 swpinnerl4offset; / 2 1 / u8 swpinnerl3offset; / 3 1 / u8 csflags; / 4 1 / u8 swpflags; / 5 1 / be16 mss; / 6 2 / be32 flowtablemetadata; / 8 4 / union { struct { be16 sz; / 12 2 / u8 start[2]; / 14 2 / } inlinehdr; / 12 4 / struct { be16 type; / 12 2 / be16 vlantci; / 14 2 / } insert; / 12 4 / be32 trailer; / 12 4 / }; / 12 4 /
/ size: 16, cachelines: 1, members: 9 / / last cacheline: 16 bytes / };
struct mlx5wqedataseg { be32 bytecount; / 0 4 / be32 lkey; / 4 4 / be64 addr; / 8 8 /
/ size: 16, cachelines: 1, members: 3 / / last cacheline: 16 bytes / };
So, split the memcpy() so the compiler can reason about the buffer sizes.
"pahole" shows no size nor member offset changes to struct mlx5etxwqe nor struct mlx5eumrwqe. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences and optimizations).
In the Linux kernel, the following vulnerability has been resolved:
memstick/msproblock: fix handling of read-only devices
Use setdiskro to propagate the read-only state to the block layer instead of checking for it in ->open and leaking a reference in case of a read-only device.
Bluetooth: hcievent: Ignore multiple conn complete events
drm/amd/pm: fix a potential gpumetricstable memory leak
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: Avoid cross-chip syncing of VLAN filtering
Changes to VLAN filtering are not applicable to cross-chip notifications.
On a system like this:
.-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-'
Before this change, upon sw1p1 leaving a bridge, a call to dsaportvlanfiltering would also be made to sw2p1 and sw3p1.
In this scenario:
.---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-'
When sw1p4 would leave a bridge, dsaportvlanfiltering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix temporary data corruption in collapse range
collapse range doesn't discard the affected cached region so can risk temporarily corrupting the file data. This fixes xfstest generic/031
I also decided to merge a minor cleanup to this into the same patch (avoiding rereading inode size repeatedly unnecessarily) to make it clearer.
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix temporary data corruption in insert range
insert range doesn't discard the affected cached region so can risk temporarily corrupting file data.
Also includes some minor cleanup (avoiding rereading inode size repeatedly unnecessarily) to make it clearer.
btrfs: scrub: handle RST lookup error correctly
In the Linux kernel, the following vulnerability has been resolved:
lib/generic-radix-tree.c: Don't overflow in peek()
When we started spreading new inode numbers throughout most of the 64 bit inode space, that triggered some corner case bugs, in particular some integer overflows related to the radix tree code. Oops.
drm/dp: Fix OOB read when handling Post Cursor2 register
hwrng: cavium - fix NULL but dereferenced coccicheck error
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum: Guard against invalid local ports
When processing events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not for the CPU port (local port 0), which exists, but does not have all the fields as any local port.
This can result in a NULL pointer dereference when trying access 'struct mlxswspport' fields which are not initialized for CPU port.
Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware") already handled such issue by bailing early when processing a PUDE event reported for the CPU port.
Generalize the approach by moving the check to a common function and making use of it in all relevant places.
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: bgmac: Fix refcount leak in bcmamdiomiiregister
ofgetchildbyname() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnodeput() to avoid refcount leak.
drm/amd/display: Wrap dcn301calculatewmanddlg for FPU.
drm/amdgpu: fix use-after-free during gpu recovery
bpf: Guard stack limits against 32bit overflow
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire SRCU in KVMGETMPSTATE to protect guest memory accesses
Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where "accepting" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT and a TRIPLEFAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->checknestedevents(), and emuating the nested VM-Exit can access guest memory.
The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triplefaulteventtest selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpumpstateget() to trigger the scenario.
============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pilockdepfalsepos-lock #3 Not tainted ----------------------------- include/linux/kvmhost.h:1058 suspicious rcudereferencecheck() usage!
other info that might help us debug this:
rcuscheduleractive = 2, debuglocks = 1 1 lock held by triplefaultev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvmvcpuioctl+0x8b/0x9a0 [kvm]
stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triplefaultev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x7f/0x90 lockdeprcususpicious+0x144/0x190 kvmvcpugfntomemslot+0x156/0x180 [kvm] kvmvcpureadguest+0x3e/0x90 [kvm] readandcheckmsrentry+0x2e/0x180 [kvmintel] nestedvmxvmexit+0x550/0xde0 [kvmintel] kvmchecknestedevents+0x1b/0x30 [kvm] kvmapicacceptevents+0x33/0x100 [kvm] kvmarchvcpuioctlgetmpstate+0x30/0x1d0 [kvm] kvmvcpuioctl+0x33e/0x9a0 [kvm] x64sysioctl+0x8b/0xb0 dosyscall64+0x6c/0x170 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK>
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: free routing table on probe failure
If complete = true in dsatreesetup(), it means that we are the last switch of the tree which is successfully probing, and we should be setting up all switches from our probe path.
After "complete" becomes true, dsatreesetupcpuports() or any subsequent function may fail. If that happens, the entire tree setup is in limbo: the first N-1 switches have successfully finished probing (doing nothing but having allocated persistent memory in the tree's dst->ports, and maybe dst->rtable), and switch N failed to probe, ending the tree setup process before anything is tangible from the user's PoV.
If switch N fails to probe, its memory (ports) will be freed and removed from dst->ports. However, the dst->rtable elements pointing to its ports, as created by dsalinktouch(), will remain there, and will lead to use-after-free if dereferenced.
If dsatreesetupswitches() returns -EPROBEDEFER, which is entirely possible because that is where ds->ops->setup() is, we get a kasan report like this:
================================================================== BUG: KASAN: slab-use-after-free in mv88e6xxxsetupupstreamport+0x240/0x568 Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42
Call trace: asanreportload8noabort+0x20/0x30 mv88e6xxxsetupupstreamport+0x240/0x568 mv88e6xxxsetup+0xebc/0x1eb0 dsaregisterswitch+0x1af4/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 deviceattachdriver+0x274/0x350
Allocated by task 42: kasankmalloc+0x84/0xa0 kmalloccachenoprof+0x298/0x490 dsaswitchtouchports+0x174/0x3d8 dsaregisterswitch+0x800/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 deviceattachdriver+0x274/0x350
Freed by task 42: kasanslabfree+0x48/0x68 kfree+0x138/0x418 dsaregisterswitch+0x2694/0x2ae0 mv88e6xxxregisterswitch+0x1b8/0x2a8 mv88e6xxxprobe+0xc4c/0xf60 mdioprobe+0x78/0xb8 reallyprobe+0x2b8/0x5a8 driverprobedevice+0x164/0x298 driverprobedevice+0x78/0x258 deviceattachdriver+0x274/0x350
The simplest way to fix the bug is to delete the routing table in its entirety. dsatreesetuproutingtable() has no problem in regenerating it even if we deleted links between ports other than those of switch N, because dsalinktouch() first checks whether the port pair already exists in dst->rtable, allocating if not.
The deletion of the routing table in its entirety already exists in dsatreeteardown(), so refactor that into a function that can also be called from the tree setup error path.
In my analysis of the commit to blame, it is the one which added dsalink elements to dst->rtable. Prior to that, each switch had its own ds->rtable which is freed when the switch fails to probe. But the tree is potentially persistent memory.
In the Linux kernel, the following vulnerability has been resolved:
nvmet: always initialize cqe.result
The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA.
Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: wait barrier before returning discard request with REQNOWAIT
raid10handlediscard should wait barrier before returning a discard bio which has REQNOWAIT. And there is no need to print warning calltrace if a discard bio has REQNOWAIT flag. Quality engineer usually checks dmesg and reports error if dmesg has warning/error calltrace.
bpf: Reject narrower access to pointer ctx fields
In the Linux kernel, the following vulnerability has been resolved:
net: fix NULL pointer dereference in l3mdevl3rcv
When delete l3s ipvlan:
ip link del link eth0 ipvlan1 type ipvlan mode l3s
This may cause a null pointer dereference:
Call trace: iprcvfinish+0x48/0xd0 iprcv+0x5c/0x100 netifreceiveskbonecore+0x64/0xb0 netifreceiveskb+0x20/0x80 processbacklog+0xb4/0x204 napipoll+0xe8/0x294 netrxaction+0xd8/0x22c dosoftirq+0x12c/0x354
This is because l3mdevl3rcv() visit dev->l3mdevops after ipvlanl3sunregister() assign the dev->l3mdevops to NULL. The process like this:
(CPU1) | (CPU2) l3mdevl3rcv() | check dev->privflags: | master = skb->dev; | | | ipvlanl3sunregister() | set dev->privflags | dev->l3mdevops = NULL; | visit master->l3mdevops |
To avoid this by do not set dev->l3mdevops when unregister l3s ipvlan.
ax25: fix use-after-free bugs caused by ax25dsdeltimer
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Fix isochronous Ring Underrun/Overrun event handling
The TRB pointer of these events points at enqueue at the time of error occurrence on xHCI 1.1+ HCs or it's NULL on older ones. By the time we are handling the event, a new TD may be queued at this ring position.
I can trigger this race by rising interrupt moderation to increase IRQ handling delay. Similar delay may occur naturally due to system load.
If this ever happens after a Missed Service Error, missed TDs will be skipped and the new TD processed as if it matched the event. It could be given back prematurely, risking data loss or buffer UAF by the xHC.
Don't complete TDs on xrun events and don't warn if queued TDs don't match the event's TRB pointer, which can be NULL or a link/no-op TRB. Don't warn if there are no queued TDs at all.
Now that it's safe, also handle xrun events if the skip flag is clear. This ensures completion of any TD stuck in 'error mid TD' state right before the xrun event, which could happen if a driver submits a finite number of URBs to a buggy HC and then an error occurs on the last TD.