Idira Endpoint Privilege Manager Agent versions prior to 26.5 exhibit improper access control within high-privileged agent components. A local, low-privileged attacker could exploit this by manipulating an internal communication mechanism or file operation. Under specific circumstances, this could potentially allow the attacker to bypass permission restrictions and execute unauthorized local actions with elevated privileges. CyberArk Security Bulletin: CA26-19

Last updated 25 April 2025

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:

KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache

There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgicitscheckcache() does not elevate the refcount on the vgicirq before dropping the lock that serializes refcount changes.

Have vgicitscheckcache() raise the refcount on the returned vgicirq and add the corresponding decrement after queueing the interrupt.

In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Remove WO permissions on second-level paging entries

When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration.

In the Linux kernel, the following vulnerability has been resolved:

ath10k: Fix a use after free in ath10khtcsendbundle

In ath10khtcsendbundle, the bundleskb could be freed by devkfreeskbany(bundleskb). But the bundleskb is used later by bundleskb->len.

As skblen = bundleskb->len, my patch replaces bundleskb->len to skblen after the bundleskb was freed.

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix uaf in smb20oplockbreakack

drop reference after use opinfo.

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:

net: fix possible store tearing in neighperiodicwork()

The Linux kernel CVE team has assigned CVE-2023-52522 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024030253-CVE-2023-52522-6abd@gregkh/T/#u

In the Linux kernel, the following vulnerability has been resolved:

net: nfc: fix races in nfcllcpsockget() and nfcllcpsockgetsn()

Sili Luo reported a race in nfcllcpsockget(), leading to UAF.

Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock.

nfcllcpsockgetsn() has a similar problem.

Finally nfcllcprecvsnl() needs to make sure the socket found by nfcllcpsockfromsn() does not disappear.

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

A use-after-free in the mac80211 stack when parsing a multi-BSSID element in the Linux kernel 5.2 through 5.19.x before 5.19.16 could be used by attackers (able to inject WLAN frames) to crash the kernel and potentially execute code.

In the Linux kernel, the following vulnerability has been resolved:

xen-netback: take a reference to the RX task thread

Do this in order to prevent the task from being freed if the thread returns (which can be triggered by the frontend) before the call to kthreadstop done as part of the backend tear down. Not taking the reference will lead to a use-after-free in that scenario. Such reference was taken before but dropped as part of the rework done in 2ac061ce97f4.

Reintroduce the reference taking and add a comment this time explaining why it's needed.

This is XSA-374 / CVE-2021-28691.

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:

scsi: lpfc: Fix listadd() corruption in lpfcdraintxq()

When parsing the txq list in lpfcdraintxq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "failmsg" string is set and a log message output. The job is then added to a completions list for cancellation.

Processing of any further jobs from the txq list continues, but since "failmsg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption.

Fix by clearing the failmsg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure.

In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix NULL ptr dereference on VSI filter sync

Remove the reason of null pointer dereference in sync VSI filters. Added new I40EVSIRELEASING flag to signalize deleting and releasing of VSI resources to sync this thread with sync filters subtask. Without this patch it is possible to start update the VSI filter list after VSI is removed, that's causing a kernel oops.

In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix link down processing to address NULL pointer dereference

If an FC link down transition while PLOGIs are outstanding to fabric well known addresses, outstanding ABTS requests may result in a NULL pointer dereference. Driver unload requests may hang with repeated "2878" log messages.

The Link down processing results in ABTS requests for outstanding ELS requests. The Abort WQEs are sent for the ELSs before the driver had set the link state to down. Thus the driver is sending the Abort with the expectation that an ABTS will be sent on the wire. The Abort request is stalled waiting for the link to come up. In some conditions the driver may auto-complete the ELSs thus if the link does come up, the Abort completions may reference an invalid structure.

Fix by ensuring that Abort set the flag to avoid link traffic if issued due to conditions where the link failed.

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:

ice: Fix crash by keep old cfg when update TCs more than queues

There are problems if allocated queues less than Traffic Classes.

Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config for DCB") already disallow setting less queues than TCs.

Another case is if we first set less queues, and later update more TCs config due to LLDP, icevsicfgtc() will failed but left dirty numtxq/rxq and tccfg in vsi, that will cause invalid pointer access.

[ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated. [ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)! [ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0 [ 95.969621] general protection fault: 0000 [#1] SMP NOPTI [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1 [ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021 [ 95.969992] RIP: 0010:devmkmalloc+0xa/0x60 [ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206 [ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0 [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200 [ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000 [ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100 [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460 [ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000 [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0 [ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 95.971530] PKRU: 55555554 [ 95.971573] Call Trace: [ 95.971622] icesetuprxring+0x39/0x110 [ice] [ 95.971695] icevsisetuprxrings+0x54/0x90 [ice] [ 95.971774] icevsiopen+0x25/0x120 [ice] [ 95.971843] iceopeninternal+0xb8/0x1f0 [ice] [ 95.971919] iceenavsi+0x4f/0xd0 [ice] [ 95.971987] icedcbenadisvsi.constprop.5+0x29/0x90 [ice] [ 95.972082] icepfdcbcfg+0x29a/0x380 [ice] [ 95.972154] icedcbnlsetets+0x174/0x1b0 [ice] [ 95.972220] dcbnlieeeset+0x89/0x230 [ 95.972279] ? dcbnlieeedel+0x150/0x150 [ 95.972341] dcbdoit+0x124/0x1b0 [ 95.972392] rtnetlinkrcvmsg+0x243/0x2f0 [ 95.972457] ? dcbdoit+0x14d/0x1b0 [ 95.972510] ? kmallocnodetrackcaller+0x1d3/0x280 [ 95.972591] ? rtnlcalcit.isra.31+0x100/0x100 [ 95.972661] netlinkrcvskb+0xcf/0xf0 [ 95.972720] netlinkunicast+0x16d/0x220 [ 95.972781] netlinksendmsg+0x2ba/0x3a0 [ 95.975891] socksendmsg+0x4c/0x50 [ 95.979032] syssendmsg+0x2e4/0x300 [ 95.982147] ? kmemcachealloc+0x13e/0x190 [ 95.985242] ? wakeupcommonlock+0x79/0x90 [ 95.988338] ? checkobjectsize+0xac/0x1b0 [ 95.991440] ? copytouser+0x22/0x30 [ 95.994539] ? moveaddrtouser+0xbb/0xd0 [ 95.997619] ? syssendmsg+0x53/0x80 [ 96.000664] syssendmsg+0x53/0x80 [ 96.003747] dosyscall64+0x5b/0x1d0 [ 96.006862] entrySYSCALL64afterhwframe+0x65/0xca

Only update numtxq/rxq when passed check, and restore tccfg if setup queue map failed.

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Fix command flush on cable pull

System crash due to command failed to flush back to SCSI layer.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x8664 #1 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvmefcconnectctrlwork [nvmefc] RIP: 0010:wakeupcommon+0x4c/0x190 Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: wakeupcommonlock+0x7c/0xc0 qlanvmelsreq+0x355/0x4c0 [qla2xxx] qla2xxx [0000:12:00.1]-f084:3: qltfreesessiondone: sesess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loopid 0x02 sid 01:02:00 logout 1 keep 0 elslogo 0 ? nvmefcsendlsreq+0x260/0x380 [nvmefc] qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200. ? nvmefcsendlsreq.constprop.42+0x1a/0x45 [nvmefc] qla2xxx [0000:12:00.1]-2109:3: qla2x00schedulerportdel 21320002ac07eeb8. rport ffff8ae598122000 roles 1 ? nvmefcconnectctrlwork.cold.63+0x1e3/0xa7d [nvmefc] qla2xxx [0000:12:00.1]-f084:3: qltfreesessiondone: sesess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loopid 0x04 sid 01:02:01 logout 1 keep 0 elslogo 0 ? switchto+0x10c/0x450 ? processonework+0x1a7/0x360 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201. ? workerthread+0x1ce/0x390 ? createworker+0x1a0/0x1a0 qla2xxx [0000:12:00.1]-2109:3: qla2x00schedulerportdel 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70 ? kthread+0x10a/0x120 qla2xxx [0000:12:00.1]-2112:3: qlanvmeunregisterremoteport: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8 ? setkthreadstruct+0x40/0x40 qla2xxx [0000:12:00.1]-2110:3: remoteportdelete of ffff8ae14801e000 21320102adf7eeb8 completed. ? retfromfork+0x1f/0x40 qla2xxx [0000:12:00.1]-f086:3: qltfreesessiondone: waiting for sess ffff8ae14801e000 logout

The system was under memory stress where driver was not able to allocate an SRB to carry out error recovery of cable pull. The failure to flush causes upper layer to start modifying scsicmnd. When the system frees up some memory, the subsequent cable pull trigger another command flush. At this point the driver access a null pointer when attempting to DMA unmap the SGL.

Add a check to make sure commands are flush back on session tear down to prevent the null pointer access.

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Write-protect L2 SPTEs in TDP MMU when clearing dirty status

Check kvmmmupageadneedwriteprotect() when deciding whether to write-protect or clear D-bits on TDP MMU SPTEs, so that the TDP MMU accounts for any role-specific reasons for disabling D-bit dirty logging.

Specifically, TDP MMU SPTEs must be write-protected when the TDP MMU is being used to run an L2 (i.e. L1 has disabled EPT) and PML is enabled. KVM always disables PML when running L2, even when L1 and L2 GPAs are in the some domain, so failing to write-protect TDP MMU SPTEs will cause writes made by L2 to not be reflected in the dirty log.

[sean: massage shortlog and changelog, tweak ternary op formatting]

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:

wifi: brcmfmac: Fix use-after-free bug in brcmfcfg80211detach

This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233

In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker:

->brcmfusbprobe ->brcmfusbprobecb ->brcmfattach ->brcmfbusstarted ->brcmfcfg80211attach ->wlinitpriv ->brcmfinitescan ->INITWORK(&cfg->escantimeoutwork, brcmfcfg80211escantimeoutworker);

If we disconnect the USB by hotplug, it will call brcmfusbdisconnect to make cleanup. The invoking chain is :

brcmfusbdisconnect ->brcmfusbdisconnectcb ->brcmfdetach ->brcmfcfg80211detach ->kfree(cfg);

While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmfcfg80211escantimeoutworker.

Fix it by deleting the timer and canceling the worker in brcmfcfg80211detach.

[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]

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:

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:

iommu/vt-d: Use device rbtree in iopf reporting path

The existing I/O page fault handler currently locates the PCI device by calling pcigetdomainbusandslot(). This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, replace it with devicerbtreefind() to search the device within the probed device rbtree.

The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after devicerbtreefind() and before iopfgetdevfaultparam(), which would cause a use-after-free problem.

Add a mutex to synchronize the I/O page fault reporting path and the IOMMU release device path. This lock doesn't introduce any performance overhead, as the conflict between I/O page fault reporting and device releasing is very rare.

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