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

crypto: aead - Fix reqsize handling

Commit afddce13ce81d ("crypto: api - Add reqsize to cryptoalg") introduced crareqsize field in cryptoalg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks.

However, this is being recommended for use in all crypto algs instead of setting reqsize using cryptosetreqsize(). Using crareqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from crareqsize. [1]

Add proper setreqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework.

[1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b

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

net/handshake: duplicate handshake cancellations leak socket

When a handshake request is cancelled it is removed from the handshakenet->hnrequests list, but it is still present in the handshakerhashtbl until it is destroyed.

If a second cancellation request arrives for the same handshake request, then removepending() will return false... and assuming HANDSHAKEFREQCOMPLETED isn't set in req->hrflags, we'll continue processing through the outtrue label, where we put another reference on the sock and a refcount underflow occurs.

This can happen for example if a handshake times out - particularly if the SUNRPC client sends the AUTHTLS probe to the server but doesn't follow it up with the ClientHello due to a problem with tlshd. When the timeout is hit on the server, the server will send a FIN, which triggers a cancellation request via xsresettransport(). When the timeout is hit on the client, another cancellation request happens via xstlshandshakesync().

Add a testandsetbit(HANDSHAKEFREQCOMPLETED) in the pending cancel path so duplicate cancels can be detected.

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

staging: rtl8723bs: fix out-of-bounds read in rtwgetie() parser

The Information Element (IE) parser rtwgetie() trusted the length byte of each IE without validating that the IE body (len bytes after the 2-byte header) fits inside the remaining frame buffer. A malformed frame can advertise an IE length larger than the available data, causing the parser to increment its pointer beyond the buffer end. This results in out-of-bounds reads or, depending on the pattern, an infinite loop.

Fix by validating that (offset + 2 + len) does not exceed the limit before accepting the IE or advancing to the next element.

This prevents OOB reads and ensures the parser terminates safely on malformed frames.

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

virtio-net: fix received length check in big packets

Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets"), when guest gso is off, the allocated size for big packets is not MAXSKBFRAGS PAGESIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->bigpacketsnumskbfrags.

Because the host announced buffer length can be malicious (e.g. the host vhostnet driver's getrxbufs is modified to announce incorrect length), we need a check in virtionet receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one.

This commit fixes the received length check corresponding to the new change.

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

gpio: cdev: make sure the cdev fd is still active before emitting events

With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier.

Using the regular getfile() routine in this situation triggers the following warning:

struct file::fcount incremented from zero; use-after-free condition present!

So use the getfileactive() variant that will return NULL on file descriptors that have been or are being released.

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

drm/ttm: Don't leak a resource on swapout move error

If moving the bo to system for swapout failed, we were leaking a resource. Fix.

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

ASoC: Intel: avs: Disable periods-elapsed work when closing PCM

avsdaifeshutdown() handles the shutdown procedure for HOST HDAudio stream while period-elapsed work services its IRQs. As the former frees the DAI's private context, these two operations shall be synchronized to avoid slab-use-after-free or worse errors.

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

drm/radeon: Remove calls to drmputdev()

Since the allocation of the drivers main structure was changed to devmdrmdevalloc() drmputdev()'ing to trigger it to be free'd should be done by devres.

However, drmputdev() is still in the probe error and device remove paths. When the driver fails to probe warnings like the following are shown because devres is trying to drmputdev() after the driver already did it.

[ 5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22 [ 5.649605] ------------[ cut here ]------------ [ 5.649607] refcountt: underflow; use-after-free. [ 5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcountwarnsaturate+0xbe/0x110

(cherry picked from commit 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4)

ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events

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

spi: tegra210-quad: Fix timeout handling

When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached.

While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the currxfer field pointing at stale memory.

To avoid this, clear currxfer to NULL upon timeout and check for this condition when the IRQ thread is finally run.

While at it, also make sure to clear interrupts on failure so that new interrupts can be run.

A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.

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

drm/panthor: Prevent potential UAF in group creation

This commit prevents the possibility of a use after free issue in the GROUPCREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUPDESTROY ioctl from another thread around the same time as GROUPCREATE ioctl.

To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUPCREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet.

v2: Add R-bs and fixes tags

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

md/raid5: Remove unnecessary bioput() in raid5readonechunk()

When running chunk-sized reads on disks with badblocks duplicate bio free/puts are observed:

============================================================================= BUG bio-200 (Not tainted): Object already free ----------------------------------------------------------------------------- Allocated in mempoolallocslab+0x17/0x20 age=3 cpu=2 pid=7504 slaballoc.constprop.0+0x5a/0xb0 kmemcachealloc+0x31e/0x330 mempoolallocslab+0x17/0x20 mempoolalloc+0x100/0x2b0 bioallocbioset+0x181/0x460 dompagereadpage+0x776/0xd00 mpagereadahead+0x166/0x320 blkdevreadahead+0x15/0x20 readpages+0x13f/0x5f0 pagecacheraunbounded+0x18d/0x220 forcepagecachera+0x181/0x1c0 pagecachesyncra+0x65/0xb0 filemapgetpages+0x1df/0xaf0 filemapread+0x1e1/0x700 blkdevreaditer+0x1e5/0x330 vfsread+0x42a/0x570 Freed in mempoolfreeslab+0x17/0x20 age=3 cpu=2 pid=7504 kmemcachefree+0x46d/0x490 mempoolfreeslab+0x17/0x20 mempoolfree+0x66/0x190 biofree+0x78/0x90 bioput+0x100/0x1a0 raid5makerequest+0x2259/0x2450 mdhandlerequest+0x402/0x600 mdsubmitbio+0xd9/0x120 submitbio+0x11f/0x1b0 submitbionoacctnocheck+0x204/0x480 submitbionoacct+0x32e/0xc70 submitbio+0x98/0x1a0 mpagereadahead+0x250/0x320 blkdevreadahead+0x15/0x20 readpages+0x13f/0x5f0 pagecacheraunbounded+0x18d/0x220 Slab 0xffffea000481b600 objects=21 used=0 fp=0xffff8881206d8940 flags=0x17ffffc0010201(locked|slab|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 0 PID: 34525 Comm: kworker/u24:2 Not tainted 6.0.0-rc2-localyes-265166-gf11c5343fa3f #143 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: raid5wq raid5dowork Call Trace: <TASK> dumpstacklvl+0x5a/0x78 dumpstack+0x10/0x16 printtrailer+0x158/0x165 objecterr+0x35/0x50 freedebugprocessing.cold+0xb7/0xbe slabfree+0x1ae/0x330 kmemcachefree+0x46d/0x490 mempoolfreeslab+0x17/0x20 mempoolfree+0x66/0x190 biofree+0x78/0x90 bioput+0x100/0x1a0 mpageendio+0x36/0x150 bioendio+0x2fd/0x360 mdendioacct+0x7e/0x90 bioendio+0x2fd/0x360 handlefailedstripe+0x960/0xb80 handlestripe+0x1348/0x3760 handleactivestripes.constprop.0+0x72a/0xaf0 raid5dowork+0x177/0x330 processonework+0x616/0xb20 workerthread+0x2bd/0x6f0 kthread+0x179/0x1b0 retfromfork+0x22/0x30 </TASK>

The double free is caused by an unnecessary bioput() in the if(isbadblock(...)) error path in raid5readonechunk().

The error path was moved ahead of bioallocclone() in c82aa1b76787c ("md/raid5: move checking badblock before clone bio in raid5readonechunk"). The previous code checked and freed alignbio which required a bioput. After the move that is no longer needed as raidbio is returned to the control of the common io path which performs its own endio resulting in a double free on bad device blocks.

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

soundwire: fix enumeration completion

The soundwire subsystem uses two completion structures that allow drivers to wait for soundwire device to become enumerated on the bus and initialised by their drivers, respectively.

The code implementing the signalling is currently broken as it does not signal all current and future waiters and also uses the wrong reinitialisation function, which can potentially lead to memory corruption if there are still waiters on the queue.

Not signalling future waiters specifically breaks sound card probe deferrals as codec drivers can not tell that the soundwire device is already attached when being reprobed. Some codec runtime PM implementations suffer from similar problems as waiting for enumeration during resume can also timeout despite the device already having been enumerated.

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

btrfs: fix incorrect splitting in btrfsdropextentmaprange

In production we were seeing a variety of WARNON()'s in the extentmap code, specifically in btrfsdropextentmaprange() when we have to call addextentmapping() for our second split.

Consider the following extent map layout

PINNED [0 16K) [32K, 48K)

and then we call btrfsdropextentmaprange for [0, 36K), with skippinned == true. The initial loop will have

start = 0 end = 36K len = 36K

we will find the [0, 16k) extent, but since we are pinned we will skip it, which has this code

start = emend; if (end != (u64)-1) len = start + len - emend;

emend here is 16K, so now the values are

start = 16K len = 16K + 36K - 16K = 36K

len should instead be 20K. This is a problem when we find the next extent at [32K, 48K), we need to split this extent to leave [36K, 48k), however the code for the split looks like this

split->start = start + len; split->len = emend - (start + len);

In this case we have

emend = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52K

and now we have an invalid extentmap in the tree that potentially overlaps other entries in the extent map. Even in the non-overlapping case we will have split->start set improperly, which will cause problems with any block related calculations.

We don't actually need len in this loop, we can simply use end as our end point, and only adjust start up when we find a pinned extent we need to skip.

Adjust the logic to do this, which keeps us from inserting an invalid extent map.

We only skippinned in the relocation case, so this is relatively rare, except in the case where you are running relocation a lot, which can happen with auto relocation on.

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

KVM: Disallow toggling KVMMEMGUESTMEMFD on an existing memslot

Reject attempts to disable KVMMEMGUESTMEMFD on a memslot that was initially created with a guestmemfd binding, as KVM doesn't support toggling KVMMEMGUESTMEMFD on existing memslots. KVM prevents enabling KVMMEMGUESTMEMFD, but doesn't prevent clearing the flag.

Failure to reject the new memslot results in a use-after-free due to KVM not unbinding from the guestmemfd instance. Unbinding on a FLAGSONLY change is easy enough, and can/will be done as a hardening measure (in anticipation of KVM supporting dirty logging on guestmemfd at some point), but fixing the use-after-free would only address the immediate symptom.

================================================================== BUG: KASAN: slab-use-after-free in kvmgmemrelease+0x362/0x400 [kvm] Write of size 8 at addr ffff8881111ae908 by task repro/745

CPU: 7 UID: 1000 PID: 745 Comm: repro Not tainted 6.18.0-rc6-115d5de2eef3-next-kasan #3 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x51/0x60 printreport+0xcb/0x5c0 kasanreport+0xb4/0xe0 kvmgmemrelease+0x362/0x400 [kvm] fput+0x2fa/0x9d0 taskworkrun+0x12c/0x200 doexit+0x6ae/0x2100 dogroupexit+0xa8/0x230 x64sysexitgroup+0x3a/0x50 x64syscall+0x737/0x740 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f581f2eac31 </TASK>

Allocated by task 745 on cpu 6 at 9.746971s: kasansavestack+0x20/0x40 kasansavetrack+0x13/0x50 kasankmalloc+0x77/0x90 kvmsetmemoryregion.part.0+0x652/0x1110 [kvm] kvmvmioctl+0x14b0/0x3290 [kvm] x64sysioctl+0x129/0x1a0 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53

Freed by task 745 on cpu 6 at 9.747467s: kasansavestack+0x20/0x40 kasansavetrack+0x13/0x50 kasansavefreeinfo+0x37/0x50 kasanslabfree+0x3b/0x60 kfree+0xf5/0x440 kvmsetmemslot+0x3c2/0x1160 [kvm] kvmsetmemoryregion.part.0+0x86a/0x1110 [kvm] kvmvmioctl+0x14b0/0x3290 [kvm] x64sysioctl+0x129/0x1a0 dosyscall64+0x5b/0x900 entrySYSCALL64afterhwframe+0x4b/0x53

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

wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cutxfilldesc()

TID getting from ieee80211gettid() might be out of range of array size of staentry->tids[], so check TID is less than MAXTIDCOUNT. Othwerwise, UBSAN warn:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 index 10 is out of range for type 'rtltiddata [9]'

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

net: octeonepvf: fix freeirq devid mismatch in IRQ rollback

octepvfrequestirqs() requests MSI-X queue IRQs with devid set to ioqvector. If requestirq() fails part-way, the rollback loop calls freeirq() with devid set to 'oct', which does not match the original devid and may leave the irqaction registered.

This can keep IRQ handlers alive while ioqvector is later freed during unwind/teardown, leading to a use-after-free or crash when an interrupt fires.

Fix the error path to free IRQs with the same ioqvector devid used during requestirq().

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

iio: dac: ad3552r-hs: fix out-of-bound write in ad3552rhswritedatasource

When simplewritetobuffer() succeeds, it returns the number of bytes actually copied to the buffer. The code incorrectly uses 'count' as the index for null termination instead of the actual bytes copied. If count exceeds the buffer size, this leads to out-of-bounds write. Add a check for the count and use the return value as the index.

The bug was validated using a demo module that mirrors the original code and was tested under QEMU.

Pattern of the bug: - A fixed 64-byte stack buffer is filled using count. - If count > 64, the code still does buf[count] = '\0', causing an - out-of-bounds write on the stack.

Steps for reproduce: - Opens the device node. - Writes 128 bytes of A to it. - This overflows the 64-byte stack buffer and KASAN reports the OOB.

Found via static analysis. This is similar to the commit da9374819eb3 ("iio: backend: fix out-of-bound write")

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

ALSA: usb-audio: Fix use-after-free in sndusbmixerfree()

When sndusbcreatemixer() fails, sndusbmixerfree() frees mixer->idelems but the controls already added to the card still reference the freed memory. Later when sndcardregister() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read.

Call trace: getctlvalue+0x63f/0x820 sound/usb/mixer.c:411 getminmaxwithquirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixerctlfeatureinfo+0x26b/0x490 sound/usb/mixer.c:1381 sndmixerossbuildtest+0x174/0x3a0 sound/core/oss/mixeross.c:887 ... sndcardregister+0x4ed/0x6d0 sound/core/init.c:923 usbaudioprobe+0x5ef/0x2a90 sound/usb/card.c:1025

Fix by calling sndctlremove() for all mixer controls before freeing idelems. We save the next pointer first because sndctlremove() frees the current element.

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

net: rds: don't hold sock lock when cancelling work from rdstcpresetcallbacks()

syzbot is reporting lockdep warning at rdstcpresetcallbacks() [1], for commit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication in rdstcpresetcallbacks()") added canceldelayedworksync() into a section protected by locksock() without realizing that rdssendxmit() might call locksock().

We don't need to protect canceldelayedworksync() using locksock(), for even if rds{send,recv}worker() re-queued this work while flushwork() from canceldelayedworksync() was waiting for this work to complete, retried rds{send,recv}worker() is no-op due to the absence of RDSCONNUP bit.

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

nvme-multipath: fix lockdep WARN due to partition scan work

Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->openmutex, kblockd workqueue completion and partitionscanwork completion.

To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partitionscanwork not by kblockd workqueue but by nvmewq.

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

libceph: return the handler error from monhandleauthdone()

Currently any error from cephauthhandlereplydone() is propagated via finishauth() but isn't returned from monhandleauthdone(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setupcrypto() and later lead to a NULL pointer dereference inside of prepareauthsignature().

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

ALSA: firewire-motu: add bounds check in putuser loop for DSP events

block: Use RCU in blkmq[un]quiescetagset() instead of set->taglistlock

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

pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domains

Fix out-of-range access of bc->domains in imx8mblkctrlremove().

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

net: cpsw: Execute ndosetrxmode callback in a work queue

Commit 1767bb2d47b7 ("ipv6: mcast: Don't hold RTNL for IPV6ADDMEMBERSHIP and MCASTJOINGROUP.") removed the RTNL lock for IPV6ADDMEMBERSHIP and MCASTJOINGROUP operations. However, this change triggered the following call trace on my BeagleBone Black board: WARNING: net/8021q/vlancore.c:236 at vlanforeach+0x120/0x124, CPU#0: rpcbind/481 RTNL: assertion failed at net/8021q/vlancore.c (236) Modules linked in: CPU: 0 UID: 997 PID: 481 Comm: rpcbind Not tainted 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT Hardware name: Generic AM33XX (Flattened Device Tree) Call trace: unwindbacktrace from showstack+0x28/0x2c showstack from dumpstacklvl+0x30/0x38 dumpstacklvl from warn+0xb8/0x11c warn from warnslowpathfmt+0x130/0x194 warnslowpathfmt from vlanforeach+0x120/0x124 vlanforeach from cpswaddmcaddr+0x54/0x98 cpswaddmcaddr from hwaddrrefsyncdev+0xc4/0xec hwaddrrefsyncdev from devmcadd+0x78/0x88 devmcadd from igmp6groupadded+0x84/0xec igmp6groupadded from ipv6devmcinc+0x1fc/0x2f0 ipv6devmcinc from ipv6sockmcjoin+0x124/0x1b4 ipv6sockmcjoin from doipv6setsockopt+0x84c/0x1168 doipv6setsockopt from ipv6setsockopt+0x88/0xc8 ipv6setsockopt from dosocksetsockopt+0xe8/0x19c dosocksetsockopt from syssetsockopt+0x84/0xac syssetsockopt from retfastsyscall+0x0/0x54

This trace occurs because vlanforeach() is called within cpswndosetrxmode(), which expects the RTNL lock to be held. Since modifying vlanforeach() to operate without the RTNL lock is not straightforward, and because ndosetrxmode() is invoked both with and without the RTNL lock across different code paths, simply adding rtnllock() in cpswndosetrxmode() is not a viable solution.

To resolve this issue, we opt to execute the actual processing within a work queue, following the approach used by the icssg-prueth driver.

Please note: To reproduce this issue, I manually reverted the changes to am335x-bone-common.dtsi from commit c477358e66a3 ("ARM: dts: am335x-bone: switch to new cpsw switch drv") in order to revert to the legacy cpsw driver.

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

wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode

Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to firmware. The P2P interfaces were available when wpasupplicant is managing the wlan interface.

However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash.

[ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmfp2psendactionframe+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmfcfg80211mgmttx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211mlmemgmttx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211txmgmt+0x238/0x388 [cfg80211] [ 1417.076281] genlfamilyrcvmsgdoit+0xe0/0x158 [ 1417.076302] genlrcvmsg+0x220/0x2a0 [ 1417.076317] netlinkrcvskb+0x68/0x140 [ 1417.076330] genlrcv+0x40/0x60 [ 1417.076343] netlinkunicast+0x330/0x3b8 [ 1417.076357] netlinksendmsg+0x19c/0x3f8 [ 1417.076370] socksendmsg+0x64/0xc0 [ 1417.076391] syssendmsg+0x268/0x2a0 [ 1417.076408] syssendmsg+0xb8/0x118 [ 1417.076427] syssendmsg+0x90/0xf8 [ 1417.076445] arm64syssendmsg+0x2c/0x40 [ 1417.076465] invokesyscall+0x50/0x120 [ 1417.076486] el0svccommon.constprop.0+0x48/0xf0 [ 1417.076506] doel0svc+0x24/0x38 [ 1417.076525] el0svc+0x30/0x100 [ 1417.076548] el0t64synchandler+0x100/0x130 [ 1417.076569] el0t64sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)

Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver.

Move initcompletion() for "sendafdone" from brcmfp2pcreatep2pdev() to brcmfp2pattach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinitcompletion() later in brcmfp2ptxactionframe(), without any prior initcompletion().

And in the brcmfp2ptxactionframe() function, the condition check for P2P Presence response frame is not needed, since the wpasupplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif.

[Cc stable]

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

ipv4: Fix reference count leak when using error routes with nexthop objects

When a nexthop object is deleted, it is marked as dead and then fibtableflush() is called to flush all the routes that are using the dead nexthop.

The current logic in fibtableflush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flushall=true). Therefore, error routes are not flushed when their nexthop object is deleted:

# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1

As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:

# ip link del dev dummy1 [ 70.516258] unregisternetdevice: waiting for dummy1 to become free. Usage count = 2

Fix by flushing error routes when their nexthop is marked as dead.

IPv6 does not suffer from this problem.

binfmtmisc: restore write access before closing files opened by openexec()