9p: avoid putting oldfid in p9clientwalk() error path

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

net: tls: fix use-after-free with partial reads and async decrypt

tlsdecryptsg doesn't take a reference on the pages from clearskb, so the putpage() in tlsdecryptdone releases them, and we trigger a use-after-free in processrxlist when we try to read from the partially-read skb.

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

smb: client: fix potential UAF in isvalidoplockbreak()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

RDMA/rxe: Fix the warning "rxecleanup+0x12c/0x170 [rdmarxe]"

The Call Trace is as below: " <TASK> ? showregs.cold+0x1a/0x1f ? rxecleanup+0x12c/0x170 [rdmarxe] ? warn+0x84/0xd0 ? rxecleanup+0x12c/0x170 [rdmarxe] ? reportbug+0x105/0x180 ? handlebug+0x46/0x80 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? rxecleanup+0x12c/0x170 [rdmarxe] ? rxecleanup+0x124/0x170 [rdmarxe] rxedestroyqp.cold+0x24/0x29 [rdmarxe] ibdestroyqpuser+0x118/0x190 [ibcore] rdmadestroyqp.cold+0x43/0x5e [rdmacm] rtrscqqpdestroy.cold+0x1d/0x2b [rtrscore] rtrssrvclosework.cold+0x1b/0x31 [rtrsserver] processonework+0x21d/0x3f0 workerthread+0x4a/0x3c0 ? processonework+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30 </TASK> " When too many rdma resources are allocated, rxe needs more time to handle these rdma resources. Sometimes with the current timeout, rxe can not release the rdma resources correctly.

Compared with other rdma drivers, a bigger timeout is used.

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

RDMA/erdma: Prevent use-after-free in erdmaacceptnewconn()

After the erdmacepput(newcep) being called, newcep will be freed, and the following dereference will cause a UAF problem. Fix this issue.

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

tls: fix handling of zero-length records on the rxlist

Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record

If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rxlist. Next recvmsg() will pick it up from there.

Queuing the skb to rxlist after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rxlist, and it's zero length.

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

NFSD: Protect against send buffer overflow in NFSv2 READDIR

Restore the previous limit on the @count argument to prevent a buffer overflow attack.

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

fs: dlm: fix race in lowcomms

This patch fixes a race between queuework() in dlmlowcommscommitmsg() and srcureadunlock(). The queuework() can take the final reference of a dlmmsg and so msg->idx can contain garbage which is signaled by the following warning:

[ 676.237050] ------------[ cut here ]------------ [ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlmlowcommscommitmsg+0x41/0x50 [ 676.238945] Modules linked in: dlmlocktorture torture rpcsecgsskrb5 intelraplmsr intelraplcommon iTCOwdt iTCOvendorsupport qxl kvmintel drmttmhelper vmwvsockvirtiotransport kvm vmwvsockvirtiotransportcommon ttm irqbypass crc32pclmul joydev crc32cintel serioraw drmkmshelper vsock virtioscsi virtioconsole virtioballoon sndpcm drm syscopyarea sysfillrect sysimgblt sndtimer fbsysfops i2ci801 lpcich snd i2csmbus soundcore pcspkr [ 676.244227] CPU: 0 PID: 1060 Comm: locktorturewr Not tainted 5.19.0-rc3+ #1546 [ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 676.246460] RIP: 0010:dlmlowcommscommitmsg+0x41/0x50 [ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 [ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282 [ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006 [ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e [ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001 [ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005 [ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480 [ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000 [ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0 [ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 676.258397] PKRU: 55555554 [ 676.258729] Call Trace: [ 676.259063] <TASK> [ 676.259354] dlmmidcommscommitmhandle+0xcc/0x110 [ 676.259964] queuebast+0x8b/0xb0 [ 676.260423] grantpendinglocks+0x166/0x1b0 [ 676.261007] unlocklock+0x75/0x90 [ 676.261469] unlocklock.isra.57+0x62/0xa0 [ 676.262009] dlmunlock+0x21e/0x330 [ 676.262457] ? locktorturestats+0x80/0x80 [dlmlocktorture] [ 676.263183] tortureunlock+0x5a/0x90 [dlmlocktorture] [ 676.263815] ? preemptcountsub+0xba/0x100 [ 676.264361] ? complete+0x1d/0x60 [ 676.264777] locktorturewriter+0xb8/0x150 [dlmlocktorture] [ 676.265555] kthread+0x10a/0x130 [ 676.266007] ? kthreadcompleteandexit+0x20/0x20 [ 676.266616] retfromfork+0x22/0x30 [ 676.267097] </TASK> [ 676.267381] irq event stamp: 9579855 [ 676.267824] hardirqs last enabled at (9579863): [<ffffffffbb14e6f8>] upconsolesem+0x58/0x60 [ 676.268896] hardirqs last disabled at (9579872): [<ffffffffbb14e6dd>] upconsolesem+0x3d/0x60 [ 676.270008] softirqs last enabled at (9579798): [<ffffffffbc200349>] dosoftirq+0x349/0x4c7 [ 676.271438] softirqs last disabled at (9579897): [<ffffffffbb0d54c0>] irqexitrcu+0xb0/0xf0 [ 676.272796] ---[ end trace 0000000000000000 ]---

I reproduced this warning with dlmlocktorture test which is currently not upstream. However this patch fix the issue by make a additional refcount between dlmlowcommsnewmsg() and dlmlowcommscommitmsg(). In case of the race the krefput() in dlmlowcommscommitmsg() will be the final put.

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

skmsg: pass gfp argument to allocskmsg()

syzbot found that allocskmsg() could be called from a non sleepable context. skpsockverdictrecv() uses rcureadlock() protection.

We need the callers to pass a gfpt argument to avoid issues.

syzbot report was:

BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 inatomic(): 0, irqsdisabled(): 0, nonblock: 0, pid: 3613, name: syz-executor414 preemptcount: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e3/0x2cb lib/dumpstack.c:106 mightresched+0x538/0x6a0 kernel/sched/core.c:9877 mightalloc include/linux/sched/mm.h:274 [inline] slabpreallochook mm/slab.h:700 [inline] slaballocnode mm/slub.c:3162 [inline] slaballoc mm/slub.c:3256 [inline] kmemcachealloctrace+0x59/0x310 mm/slub.c:3287 kmalloc include/linux/slab.h:600 [inline] kzalloc include/linux/slab.h:733 [inline] allocskmsg net/core/skmsg.c:507 [inline] skpsockskbingressself+0x5c/0x330 net/core/skmsg.c:600 skpsockverdictapply+0x395/0x440 net/core/skmsg.c:1014 skpsockverdictrecv+0x34d/0x560 net/core/skmsg.c:1201 tcpreadskb+0x4a1/0x790 net/ipv4/tcp.c:1770 tcprcvestablished+0x129d/0x1a10 net/ipv4/tcpinput.c:5971 tcpv4dorcv+0x479/0xac0 net/ipv4/tcpipv4.c:1681 skbacklogrcv include/net/sock.h:1109 [inline] releasesock+0x1d8/0x4c0 net/core/sock.c:2906 releasesock+0x5d/0x1c0 net/core/sock.c:3462 tcpsendmsg+0x36/0x40 net/ipv4/tcp.c:1483 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline] syssendto+0x46d/0x5f0 net/socket.c:2117 dosyssendto net/socket.c:2129 [inline] sesyssendto net/socket.c:2125 [inline] x64syssendto+0xda/0xf0 net/socket.c:2125 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

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

NFSD: Protect against send buffer overflow in NFSv2 READ

Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time.

Once an RPC Call has been received, svcprocess() updates svcrqst::rqres to describe the part of rqpages that can be used for constructing the Reply. This means that the send buffer (rqres) shrinks when the received RPC record containing the RPC Call is large.

A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case.

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

tls: make sure to abort the stream if headers are bogus

Normally we wait for the socket to buffer up the whole record before we service it. If the socket has a tiny buffer, however, we read out the data sooner, to prevent connection stalls. Make sure that we abort the connection when we find out late that the record is actually invalid. Retrying the parsing is fine in itself but since we copy some more data each time before we parse we can overflow the allocated skb space.

Constructing a scenario in which we're under pressure without enough data in the socket to parse the length upfront is quite hard. syzbot figured out a way to do this by serving us the header in small OOB sends, and then filling in the recvbuf with a large normal send.

Make sure that tlsrxmsgsize() aborts strp, if we reach an invalid record there's really no way to recover.

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

svcrdma: bound check rqpages index in inline path

svcrdmacopyinlinerange indexed rqstp->rqpages[rccurpage] without verifying rccurpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.

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

PCI: dwc: ep: Prevent changing BAR size/flags in pciepcsetbar()

In commit 4284c88fff0e ("PCI: designware-ep: Allow pciepcsetbar() update inbound map address") setbar() was modified to support dynamically changing the backing physical address of a BAR that was already configured.

This means that setbar() can be called twice, without ever calling clearbar() (as calling clearbar() would clear the BAR's PCI address assigned by the host).

This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks.

If we allow setbar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pciepfbar.

While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.)

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

USB: core: Fix access violation during port device removal

Testing with KASAN and syzkaller revealed a bug in port.c:disablestore(): usbhubtostructhub() can return NULL if the hub that the port belongs to is concurrently removed, but the function does not check for this possibility before dereferencing the returned value.

It turns out that the first dereference is unnecessary, since hub->intfdev is the parent of the port device, so it can be changed easily. Adding a check for hub == NULL prevents further problems.

The same bug exists in the disableshow() routine, and it can be fixed the same way.

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

nvmet-auth: validate reply message payload bounds against transfer length

nvmetauthreply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes.

A malicious NVMe-oF initiator can craft a DHCHAPREPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2hl) or performs the host response memcmp.

With DH authentication configured, the OOB pointer is passed directly to sginitone() and read by cryptokppcomputesharedsecret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication.

Add bounds validation ensuring sizeof(data) + 2hl + dhvlen <= tl before any access to the variable-length fields.

Discovered by Atuin - Automated Vulnerability Discovery Engine.

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.

can: hi311x: hi3110canist(): fix potential use-after-free

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

NFSD: fix use-after-free on source server when doing inter-server copy

Use-after-free occurred when the laundromat tried to free expired cpntfstate entry on the s2scpstateids list after inter-server copy completed. The sccplist that the expired copy state was inserted on was already freed.

When COPY completes, the Linux client normally sends LOCKU(lockstate x), FREESTATEID(lockstate x) and CLOSE(openstate y) to the source server. The nfs4putstid call from nfsd4freestateid cleans up the copy state from the s2scpstateids list before freeing the lock state's stid.

However, sometimes the CLOSE was sent before the FREESTATEID request. When this happens, the nfsd4closeopenstateid call from nfsd4close frees all lock states on its stlocks list without cleaning up the copy state on the sccplist list. When the time the FREESTATEID arrives the server returns BADSTATEID since the lock state was freed. This causes the use-after-free error to occur when the laundromat tries to free the expired cpntfstate.

This patch adds a call to nfs4freecpntfstatelist in nfsd4closeopenstateid to clean up the copy state before calling freeolstateidreaplist to free the lock state's stid on the reaplist.

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

Bluetooth: L2CAP: Fix user-after-free

This uses l2capchanholdunlesszero() after calling l2capgetchanblah() to prevent the following trace:

Bluetooth: l2capcore.c:static void l2capchandestroy(struct kref kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in mutexwaiterisfirst kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in mutexlockcommon kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in mutexlock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389

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

wifi: mac80211: fix use-after-free

We've already freed the assocdata at this point, so need to use another copy of the AP (MLD) address instead.

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

Bluetooth: hcisysfs: Fix attempting to call deviceadd multiple times

deviceadd shall not be called multiple times as stated in its documentation:

'Do not call this routine or deviceregister() more than once for any device structure'

Syzkaller reports a bug as follows [1]: ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:33! invalid opcode: 0000 [#1] PREEMPT SMP KASAN [...] Call Trace: <TASK> listadd include/linux/list.h:69 [inline] listaddtail include/linux/list.h:102 [inline] kobjksetjoin lib/kobject.c:164 [inline] kobjectaddinternal+0x18f/0x8f0 lib/kobject.c:214 kobjectaddvarg lib/kobject.c:358 [inline] kobjectadd+0x150/0x1c0 lib/kobject.c:410 deviceadd+0x368/0x1e90 drivers/base/core.c:3452 hciconnaddsysfs+0x9b/0x1b0 net/bluetooth/hcisysfs.c:53 hcilecisestabilishedevt+0x57c/0xae0 net/bluetooth/hcievent.c:6799 hcilemetaevt+0x2b8/0x510 net/bluetooth/hcievent.c:7110 hcieventfunc net/bluetooth/hcievent.c:7440 [inline] hcieventpacket+0x63d/0xfd0 net/bluetooth/hcievent.c:7495 hcirxwork+0xae7/0x1230 net/bluetooth/hcicore.c:4007 processonework+0x991/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306 </TASK>

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

cifs: Fix locking usage for tcon fields

We used to use the cifstcpseslock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srvlock, seslock and tclock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization.

There were still a couple of uses of cifstcpseslock to provide tcon fields. In this patch, I've replaced them with tclock.

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

wifi: mac80211: remove station if connection prep fails

If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any "newsta" is already being removed, so that doesn't need changes.

This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs.

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

KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic

kvms390pciaifenable(), kvms390pciaifdisable(), and aenhostforward() index the GAIT by manually multiplying the index with sizeof(struct zpcigaite).

Since aift->gait is already a struct zpcigaite pointer, this double-scales the offset, accessing element aisb16 instead of aisb.

This causes out-of-bounds accesses when aisb >= 32 (with ZPCINRDEVICES=512)

Fix by removing the erroneous sizeof multiplication.

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

perf/x86/intel: KVM: Mask PEBSENABLE loaded for guest with vCPU's value.

When generating the MSRIA32PEBSENABLE value that will be loaded on VM-Entry to a KVM guest, mask the value with the vCPU's desired PEBSENABLE value. Consulting only the host kernel's host vs. guest masks results in running the guest with PEBS enabled even when the guest doesn't want to use PEBS. Because KVM uses perf events to proxy the guest virtual PMU, simply looking at excludehost can't differentiate between events created by host userspace, and events created by KVM on behalf of the guest.

Running the guest with PEBS unexpectedly enabled typically manifests as crashes due to a near-infinite stream of #PFs. E.g. if the guest hasn't written MSRIA32DSAREA, the CPU will hit page faults on address '0' when trying to record PEBS events.

The issue is most easily reproduced by running perf kvm top from before commit 7b100989b4f6 ("perf evlist: Remove evlistadddefault") (after which, perf kvm top effectively stopped using PEBS). The userspace side of perf creates a guest-only PEBS event, which intelguestgetmsrs() misconstrues a guest-owned PEBS event.

Arguably, this is a userspace bug, as enabling PEBS on guest-only events simply cannot work, and userspace can kill VMs in many other ways (there is no danger to the host). However, even if this is considered to be bad userspace behavior, there's zero downside to perf/KVM restricting PEBS to guest-owned events.

Note, commit 854250329c02 ("KVM: x86/pmu: Disable guest PEBS temporarily in two rare situations") fixed the case where host userspace is profiling KVM and userspace, but missed the case where userspace is profiling only KVM.

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

ipv4: account for fraggap on the paged allocation path

In ipappenddata(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as

alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen;

datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skbcopyandcsumbits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount.

The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen.

After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.

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

s390/vfio-ap: always filter entire AP matrix

The vfioapmdevfiltermatrix function is called whenever a new adapter or domain is assigned to the mdev. The purpose of the function is to update the guest's AP configuration by filtering the matrix of adapters and domains assigned to the mdev. When an adapter or domain is assigned, only the APQNs associated with the APID of the new adapter or APQI of the new domain are inspected. If an APQN does not reference a queue device bound to the vfioap device driver, then it's APID will be filtered from the mdev's matrix when updating the guest's AP configuration.

Inspecting only the APID of the new adapter or APQI of the new domain will result in passing AP queues through to a guest that are not bound to the vfioap device driver under certain circumstances. Consider the following:

guest's AP configuration (all also assigned to the mdev's matrix): 14.0004 14.0005 14.0006 16.0004 16.0005 16.0006

unassign domain 4 unbind queue 16.0005 assign domain 4

When domain 4 is re-assigned, since only domain 4 will be inspected, the APQNs that will be examined will be: 14.0004 16.0004

Since both of those APQNs reference queue devices that are bound to the vfioap device driver, nothing will get filtered from the mdev's matrix when updating the guest's AP configuration. Consequently, queue 16.0005 will get passed through despite not being bound to the driver. This violates the linux device model requirement that a guest shall only be given access to devices bound to the device driver facilitating their pass-through.

To resolve this problem, every adapter and domain assigned to the mdev will be inspected when filtering the mdev's matrix.

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

mptcp: fix data races on remoteid

Similar to the previous patch, address the data race on remoteid, adding the suitable ONCE annotations.

A buffer overflow flaw was found in the u8 overflow in cfg80211updatenotlistednontrans() in net/wireless/scan.c in the Linux kernel’s wifi subcomponent. This flaw allows an attacker to crash the system or leak internal kernel information.

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

nvmet-auth: assign dhkey to NULL after kfreesensitive

ctrl-&gt;dhkey might be used across multiple calls to nvmetsetupdhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmetdestroyauth().

Found by Linux Verification Center (linuxtesting.org) with Svace.