fbdev: smscufx: properly copy ioctl memory to kernelspace

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

netfilter: nftables: fix use-after-free in nftablesaddchain()

nftablesaddchain() publishes the chain to table->chains via listaddtailrcu() (in nftchainadd()) before registering hooks. If nftablesregisterhook() then fails, the error path calls nftchaindel() (listdelrcu()) followed by nftableschaindestroy() with no RCU grace period in between.

This creates two use-after-free conditions:

1) Control-plane: nftablesdumpchains() traverses table->chains under rcureadlock(). A concurrent dump can still be walking the chain when the error path frees it.

2) Packet path: for NFPROTOINET, nfregisternethook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nftdochain() via the transient IPv4 hook can still be dereferencing chain->blobgenX when the error path frees the chain.

Add synchronizercu() between nftchaindel() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.

bonding: annotate data-races around slave->lastrx

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

can: gsusb: gsusbreceivebulkcallback(): fix error message

Sinc commit 79a6d1bfe114 ("can: gsusb: gsusbreceivebulkcallback(): unanchor URL on usbsubmiturb() error") a failing resubmit URB will print an info message.

In the case of a short read where netdev has not yet been assigned, initialize as NULL to avoid dereferencing an undefined value. Also report the error value of the failed resubmit.

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

perf: Fix refcount warning on event->mmapcount increment

When calling refcountinc(&event->mmapcount) inside perfmmaprb(), the following warning is triggered:

refcountt: addition on 0; use-after-free. WARNING: lib/refcount.c:25

PoC:

struct perfeventattr attr = {0}; int fd = syscall(NRperfeventopen, &attr, 0, -1, -1, 0); mmap(NULL, 0x3000, PROTREAD | PROTWRITE, MAPSHARED, fd, 0); int victim = syscall(NRperfeventopen, &attr, 0, -1, fd, PERFFLAGFDOUTPUT); mmap(NULL, 0x3000, PROTREAD | PROTWRITE, MAPSHARED, victim, 0);

This occurs when creating a group member event with the flag PERFFLAGFDOUTPUT. The group leader should be mmap-ed and then mmap-ing the event triggers the warning.

Since the event has copied the outputevent in perfeventsetoutput(), event->rb is set. As a result, perfmmaprb() calls refcountinc(&event->mmapcount) when event->mmapcount = 0.

Disallow the case when event->mmapcount = 0. This also prevents two events from updating the same userpage.

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

can: usb8dev: usb8devreadbulkcallback(): fix URB memory leak

Fix similar memory leak as in commit 7352e1d5932a ("can: gsusb: gsusbreceivebulkcallback(): fix URB memory leak").

In usb8devopen() -> usb8devstart(), the URBs for USB-in transfers are allocated, added to the priv->rxsubmitted anchor and submitted. In the complete callback usb8devreadbulkcallback(), the URBs are processed and resubmitted. In usb8devclose() -> unlinkallurbs() the URBs are freed by calling usbkillanchoredurbs(&priv->rxsubmitted).

However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usbkillanchoredurbs().

Fix the memory leak by anchoring the URB in the usb8devreadbulkcallback() to the priv->rxsubmitted anchor.

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

fou: Don't allow 0 for FOUATTRIPPROTO.

fouudprecv() has the same problem mentioned in the previous patch.

If FOUATTRIPPROTO is set to 0, skb is not freed by fouudprecv() nor "resubmit"-ted in ipprotocoldeliverrcu().

Let's forbid 0 for FOUATTRIPPROTO.

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

crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec

authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, cryptoauthencesndecrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalkmapandcopy(), leading to a kernel panic (DoS).

Add a minimum AAD length check to fail fast on invalid inputs.

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

LoongArch: KVM: Fix kvmdevice leak in kvmipidestroy()

In kvmioctlcreatedevice(), kvmdevice has allocated memory, kvmdevice->destroy() seems to be supposed to free its kvmdevice struct, but kvmipidestroy() is not currently doing this, that would lead to a memory leak.

So, fix it.

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

xhci: sideband: don't dereference freed ring when removing sideband endpoint

xhcisidebandremoveendpoint() incorrecly assumes that the endpoint is running and has a valid transfer ring.

Lianqin reported a crash during suspend/wake-up stress testing, and found the cause to be dereferencing a non-existing transfer ring 'ep->ring' during xhcisidebandremoveendpoint().

The endpoint and its ring may be in unknown state if this function is called after xHCI was reinitialized in resume (lost power), or if device is being re-enumerated, disconnected or endpoint already dropped.

Fix this by both removing unnecessary ring access, and by checking ep->ring exists before dereferencing it. Also make sure endpoint is running before attempting to stop it.

Remove the xhciinitializeringinfo() call during sideband endpoint removal as is it only initializes ring structure enqueue, dequeue and cycle state values to their starting values without changing actual hardware enqueue, dequeue and cycle state. Leaving them out of sync is worse than leaving it as it is. The endpoint will get freed in after this in most usecases.

If the (audio) class driver want's to reuse the endpoint after offload then it is up to the class driver to ensure endpoint is properly set up.

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

bpf: Fix reference count leak in bpfprogtestrunxdp()

syzbot is reporting

unregisternetdevice: waiting for sit0 to become free. Usage count = 2

problem. A debug printk() patch found that a refcount is obtained at xdpconvertmdtobuff() from bpfprogtestrunxdp().

According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdpmd context in BPFPROGTESTRUN"), the refcount obtained by xdpconvertmdtobuff() will be released by xdpconvertbufftomd().

Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpfprogtestrunxdp()") forgot to call xdpconvertbufftomd().

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

btrfs: fix use-after-free warning in btrfsgetorcreatedelayednode()

Previously, btrfsgetorcreatedelayednode() set the delayednode's refcount before acquiring the root->delayednodes lock. Commit e8513c012de7 ("btrfs: implement reftracker for delayednodes") moved refcountset inside the critical section, which means there is no longer a memory barrier between setting the refcount and setting btrfsinode->delayednode.

Without that barrier, the stores to node->refs and btrfsinode->delayednode may become visible out of order. Another thread can then read btrfsinode->delayednode and attempt to increment a refcount that hasn't been set yet, leading to a refcounting bug and a use-after-free warning.

The fix is to move refcountset back to where it was to take advantage of the implicit memory barrier provided by lock acquisition.

Because the allocations now happen outside of the lock's critical section, they can use GFPNOFS instead of GFPATOMIC.

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

net: usb: rtl8150: fix memory leak on usbsubmiturb() failure

In asyncsetregisters(), when usbsubmiturb() fails, the allocated asyncreq structure and URB are not freed, causing a memory leak.

The completion callback asyncsetregcb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked.

Fix this by freeing both the URB and the request structure in the error path when usbsubmiturb() fails.

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

mptcp: ensure context reset on disconnect()

After the blamed commit below, if the MPC subflow is already in TCPCLOSE status or has fallback to TCP at mptcpdisconnect() time, mptcpdofastclose() skips setting the sendfastclose flag and the later mptcpclosessk() does not reset anymore the related subflow context.

Any later connection will be created with both the requestmptcp flag and the msk-level fallback status off (it is unconditionally cleared at MPTCP disconnect time), leading to a warning in subflowdataready():

WARNING: CPU: 26 PID: 8996 at net/mptcp/subflow.c:1519 subflowdataready (net/mptcp/subflow.c:1519 (discriminator 13)) Modules linked in: CPU: 26 UID: 0 PID: 8996 Comm: syz.22.39 Not tainted 6.18.0-rc7-05427-g11fc074f6c36 #1 PREEMPT(voluntary) Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 RIP: 0010:subflowdataready (net/mptcp/subflow.c:1519 (discriminator 13)) Code: 90 0f 0b 90 90 e9 04 fe ff ff e8 b7 1e f5 fe 89 ee bf 07 00 00 00 e8 db 19 f5 fe 83 fd 07 0f 84 35 ff ff ff e8 9d 1e f5 fe 90 <0f> 0b 90 e9 27 ff ff ff e8 8f 1e f5 fe 4c 89 e7 48 89 de e8 14 09 RSP: 0018:ffffc9002646fb30 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88813b218000 RCX: ffffffff825c8435 RDX: ffff8881300b3580 RSI: ffffffff825c8443 RDI: 0000000000000005 RBP: 000000000000000b R08: ffffffff825c8435 R09: 000000000000000b R10: 0000000000000005 R11: 0000000000000007 R12: ffff888131ac0000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f88330af6c0(0000) GS:ffff888a93dd2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88330aefe8 CR3: 000000010ff59000 CR4: 0000000000350ef0 Call Trace: <TASK> tcpdataready (net/ipv4/tcpinput.c:5356) tcpdataqueue (net/ipv4/tcpinput.c:5445) tcprcvstateprocess (net/ipv4/tcpinput.c:7165) tcpv4dorcv (net/ipv4/tcpipv4.c:1955) releasesock (include/net/sock.h:1158 (discriminator 6) net/core/sock.c:3180 (discriminator 6)) releasesock (net/core/sock.c:3737) mptcpsendmsg (net/mptcp/protocol.c:1763 net/mptcp/protocol.c:1857) inetsendmsg (net/ipv4/afinet.c:853 (discriminator 7)) syssendto (net/socket.c:727 (discriminator 15) net/socket.c:742 (discriminator 15) net/socket.c:2244 (discriminator 15)) x64syssendto (net/socket.c:2247) dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) RIP: 0033:0x7f883326702d

Address the issue setting an explicit fastclosing flag at fastclose time, and checking such flag after mptcpdofastclose().

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

LoongArch: BPF: Sign extend kfunc call arguments

The kfunc calls are native calls so they should follow LoongArch calling conventions. Sign extend its arguments properly to avoid kernel panic. This is done by adding a new emitabiext() helper. The emitabiext() helper performs extension in place meaning a value already store in the target register (Note: this is different from the existing signextend() helper and thus we can't reuse it).

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

erspan: Initialize optionslen before referencing options.

The struct iptunnelinfo has a flexible array member named options that is protected by a countedby(optionslen) attribute.

The compiler will use this information to enforce runtime bounds checking deployed by FORTIFYSOURCE string helpers.

As laid out in the GCC documentation, the counter must be initialized before the first reference to the flexible array member.

After scanning through the files that use struct iptunnelinfo and also refer to options or optionslen, it appears the normal case is to use the iptunnelinfooptsset() helper.

Said helper would initialize optionslen properly before copying data into options, however in the GRE ERSPAN code a partial update is done, preventing the use of the helper function.

Before this change the handling of ERSPAN traffic in GRE tunnels would cause a kernel panic when the kernel is compiled with GCC 15+ and having FORTIFYSOURCE configured:

memcpy: detected buffer overflow: 4 byte write of buffer size 0

Call Trace: <IRQ> fortifypanic+0xd/0xf erspanrcv.cold+0x68/0x83 ? iprouteinputslow+0x816/0x9d0 grercv+0x1b2/0x1c0 grercv+0x8e/0x100 ? rawv4input+0x2a0/0x2b0 ipprotocoldeliverrcu+0x1ea/0x210 iplocaldeliverfinish+0x86/0x110 iplocaldeliver+0x65/0x110 ? iprcvfinishcore+0xd6/0x360 iprcv+0x186/0x1a0

Reported-at: https://launchpad.net/bugs/2129580

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

Input: lkkbd - disable pending work before freeing device

lkkbdinterrupt() schedules lk->tq via schedulework(), and the work handler lkkbdreinit() dereferences the lkkbd structure and its serio/inputdev fields.

lkkbddisconnect() and error paths in lkkbdconnect() free the lkkbd structure without preventing the reinit work from being queued again until serioclose() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.

Use disableworksync() instead of cancelworksync() to ensure the reinit work cannot be re-queued, and call it both in lkkbddisconnect() and in lkkbdconnect() error paths after serioopen().

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

iommu/mediatek: fix use-after-free on probe deferral

The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers.

Fix this by keeping the references as expected while the iommu driver is bound.

ethtool: Avoid overflowing userspace buffer on stats query

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

xfs: fix a UAF problem in xattr repair

The xchksetupxattrbuf function can allocate a new value buffer, which means that any reference to ab->value before the call could become a dangling pointer. Fix this by moving an assignment to after the buffer setup.

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

net/mlx5e: Avoid unregistering PSP twice

PSP is unregistered twice in: mlx5eremove -> mlx5epspunregister mlx5eniccleanup -> mlx5epspunregister

This leads to a refcount underflow in some conditions: ------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 2 PID: 1694 at lib/refcount.c:28 refcountwarnsaturate+0xd8/0xe0 [...] mlx5epspunregister+0x26/0x50 [mlx5core] mlx5eniccleanup+0x26/0x90 [mlx5core] mlx5eremove+0xe6/0x1f0 [mlx5core] auxiliarybusremove+0x18/0x30 devicereleasedriverinternal+0x194/0x1f0 busremovedevice+0xc6/0x130 devicedel+0x159/0x3c0 mlx5rescandriverslocked+0xbc/0x2a0 [mlx5core] [...]

Do not directly remove psp from the mlx5eremove path, the PSP cleanup happens as part of profile cleanup.

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

mt76: mt7615: Fix memory leak in mt7615mcuwtblstaadd()

In mt7615mcuwtblstaadd(), an skb sskb is allocated. If the subsequent call to mt76connacmcuallocwtblreq() fails, the function returns an error without freeing sskb, leading to a memory leak.

Fix this by calling devkfreeskb() on sskb in the error handling path to ensure it is properly released.

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

crypto: qat - fix out-of-bounds read

When preparing an AER-CTR request, the driver copies the key provided by the user into a data structure that is accessible by the firmware. If the target device is QAT GEN4, the key size is rounded up by 16 since a rounded up size is expected by the device. If the key size is rounded up before the copy, the size used for copying the key might be bigger than the size of the region containing the key, causing an out-of-bounds read.

Fix by doing the copy first and then update the keylen.

This is to fix the following warning reported by KASAN:

[ 138.150574] BUG: KASAN: global-out-of-bounds in qatalgskcipherinitcom.isra.0+0x197/0x250 [intelqat] [ 138.150641] Read of size 32 at addr ffffffff88c402c0 by task cryptomgrtest/2340

[ 138.150651] CPU: 15 PID: 2340 Comm: cryptomgrtest Not tainted 6.2.0-rc1+ #45 [ 138.150659] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.86B.0087.D13.2208261706 08/26/2022 [ 138.150663] Call Trace: [ 138.150668] <TASK> [ 138.150922] kasancheckrange+0x13a/0x1c0 [ 138.150931] memcpy+0x1f/0x60 [ 138.150940] qatalgskcipherinitcom.isra.0+0x197/0x250 [intelqat] [ 138.151006] qatalgskcipherinitsessions+0xc1/0x240 [intelqat] [ 138.151073] cryptoskciphersetkey+0x82/0x160 [ 138.151085] ? preparekeybuf+0xa2/0xd0 [ 138.151095] testskcipherveccfg+0x2b8/0x800

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

cxl/pmem: Fix nvdimm registration races

A loop of the form:

while true; do modprobe cxlpci; modprobe -r cxlpci; done

...fails with the following crash signature:

BUG: kernel NULL pointer dereference, address: 0000000000000040 [..] RIP: 0010:cxlinternalsendcmd+0x5/0xb0 [cxlcore] [..] Call Trace: <TASK> cxlpmemctl+0x121/0x240 [cxlpmem] nvdimmgetconfigdata+0xd6/0x1a0 [libnvdimm] ndlabeldatainit+0x135/0x7e0 [libnvdimm] nvdimmprobe+0xd6/0x1c0 [libnvdimm] nvdimmbusprobe+0x7a/0x1e0 [libnvdimm] reallyprobe+0xde/0x380 driverprobedevice+0x78/0x170 driverprobedevice+0x1f/0x90 deviceattachdriver+0x85/0x110 busforeachdrv+0x7d/0xc0 deviceattach+0xb4/0x1e0 busprobedevice+0x9f/0xc0 deviceadd+0x445/0x9c0 ndasyncdeviceregister+0xe/0x40 [libnvdimm] asyncrunentryfn+0x30/0x130

...namely that the bottom half of async nvdimm device registration runs after the CXL has already torn down the context that cxlpmemctl() needs. Unlike the ACPI NFIT case that benefits from launching multiple nvdimm device registrations in parallel from those listed in the table, CXL is already marked PROBEPREFERASYNCHRONOUS. So provide for a synchronous registration path to preclude this scenario.

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

RDMA/rxe: Fix NULL-ptr-deref in rxeqpdocleanup() when socket create failed

There is a null-ptr-deref when mount.cifs over rdma:

BUG: KASAN: null-ptr-deref in rxeqpdocleanup+0x2f3/0x360 [rdmarxe] Read of size 8 at addr 0000000000000018 by task mount.cifs/3046

CPU: 2 PID: 3046 Comm: mount.cifs Not tainted 6.1.0-rc5+ #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc3 Call Trace: <TASK> dumpstacklvl+0x34/0x44 kasanreport+0xad/0x130 rxeqpdocleanup+0x2f3/0x360 [rdmarxe] executeinprocesscontext+0x25/0x90 rxecleanup+0x101/0x1d0 [rdmarxe] rxecreateqp+0x16a/0x180 [rdmarxe] createqp.part.0+0x27d/0x340 ibcreateqpkernel+0x73/0x160 rdmacreateqp+0x100/0x230 smbdgetconnection+0x752/0x20f0 smbdgetconnection+0x21/0x40 cifsgettcpsession+0x8ef/0xda0 mountgetconns+0x60/0x750 cifsmount+0x103/0xd00 cifssmb3domount+0x1dd/0xcb0 smb3gettree+0x1d5/0x300 vfsgettree+0x41/0xf0 pathmount+0x9b3/0xdd0 x64sysmount+0x190/0x1d0 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0

The root cause of the issue is the socket create failed in rxeqpinitreq().

So move the reset rxeqpdocleanup() after the NULL ptr check.

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

RDMA/irdma: Fix data race on CQP completion stats

CQP completion statistics is read lockesly in irdmawaitevent and irdmacheckcqpprogress while it can be updated in the completion thread irdmascccqgetcqeinfo on another CPU as KCSAN reports.

Make completion statistics an atomic variable to reflect coherent updates to it. This will also avoid load/store tearing logic bug potentially possible by compiler optimizations.

[77346.170861] BUG: KCSAN: data-race in irdmahandlecqpop [irdma] / irdmascccqgetcqeinfo [irdma]

[77346.171383] write to 0xffff8a3250b108e0 of 8 bytes by task 9544 on cpu 4: [77346.171483] irdmascccqgetcqeinfo+0x27a/0x370 [irdma] [77346.171658] irdmacqpcehandler+0x164/0x270 [irdma] [77346.171835] cqpcomplworker+0x1b/0x20 [irdma] [77346.172009] processonework+0x4d1/0xa40 [77346.172024] workerthread+0x319/0x700 [77346.172037] kthread+0x180/0x1b0 [77346.172054] retfromfork+0x22/0x30

[77346.172136] read to 0xffff8a3250b108e0 of 8 bytes by task 9838 on cpu 2: [77346.172234] irdmahandlecqpop+0xf4/0x4b0 [irdma] [77346.172413] irdmacqpaeqcmd+0x75/0xa0 [irdma] [77346.172592] irdmacreateaeq+0x390/0x45a [irdma] [77346.172769] irdmartinithw.cold+0x212/0x85d [irdma] [77346.172944] irdmaprobe+0x54f/0x620 [irdma] [77346.173122] auxiliarybusprobe+0x66/0xa0 [77346.173137] reallyprobe+0x140/0x540 [77346.173154] driverprobedevice+0xc7/0x220 [77346.173173] driverprobedevice+0x5f/0x140 [77346.173190] driverattach+0xf0/0x2c0 [77346.173208] busforeachdev+0xa8/0xf0 [77346.173225] driverattach+0x29/0x30 [77346.173240] busadddriver+0x29c/0x2f0 [77346.173255] driverregister+0x10f/0x1a0 [77346.173272] auxiliarydriverregister+0xbc/0x140 [77346.173287] irdmainitmodule+0x55/0x1000 [irdma] [77346.173460] dooneinitcall+0x7d/0x410 [77346.173475] doinitmodule+0x81/0x2c0 [77346.173491] loadmodule+0x1232/0x12c0 [77346.173506] dosysfinitmodule+0x101/0x180 [77346.173522] x64sysfinitmodule+0x3c/0x50 [77346.173538] dosyscall64+0x39/0x90 [77346.173553] entrySYSCALL64afterhwframe+0x63/0xcd

[77346.173634] value changed: 0x0000000000000094 -> 0x0000000000000095

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

RDMA/irdma: Fix data race on CQP request done

KCSAN detects a data race on cqprequest->requestdone memory location which is accessed locklessly in irdmahandlecqpop while being updated in irdmacqpcehandler.

Annotate lockless intent with READONCE/WRITEONCE to avoid any compiler optimizations like load fusing and/or KCSAN warning.

[222808.417128] BUG: KCSAN: data-race in irdmacqpcehandler [irdma] / irdmawaitevent [irdma]

[222808.417532] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5: [222808.417610] irdmacqpcehandler+0x21e/0x270 [irdma] [222808.417725] cqpcomplworker+0x1b/0x20 [irdma] [222808.417827] processonework+0x4d1/0xa40 [222808.417835] workerthread+0x319/0x700 [222808.417842] kthread+0x180/0x1b0 [222808.417852] retfromfork+0x22/0x30

[222808.417918] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1: [222808.417995] irdmawaitevent+0x1e2/0x2c0 [irdma] [222808.418099] irdmahandlecqpop+0xae/0x170 [irdma] [222808.418202] irdmacqpcqdestroycmd+0x70/0x90 [irdma] [222808.418308] irdmapudadelersrc+0x46d/0x4d0 [irdma] [222808.418411] irdmartdeinithw+0x179/0x1d0 [irdma] [222808.418514] irdmaibdeallocdevice+0x11/0x40 [irdma] [222808.418618] ibdeallocdevice+0x2a/0x120 [ibcore] [222808.418823] ibunregisterdevice+0xde/0x100 [ibcore] [222808.418981] ibunregisterdevice+0x22/0x40 [ibcore] [222808.419142] irdmaibunregisterdevice+0x70/0x90 [irdma] [222808.419248] i40iwclose+0x6f/0xc0 [irdma] [222808.419352] i40eclientdeviceunregister+0x14a/0x180 [i40e] [222808.419450] i40iwremove+0x21/0x30 [irdma] [222808.419554] auxiliarybusremove+0x31/0x50 [222808.419563] deviceremove+0x69/0xb0 [222808.419572] devicereleasedriverinternal+0x293/0x360 [222808.419582] driverdetach+0x7c/0xf0 [222808.419592] busremovedriver+0x8c/0x150 [222808.419600] driverunregister+0x45/0x70 [222808.419610] auxiliarydriverunregister+0x16/0x30 [222808.419618] irdmaexitmodule+0x18/0x1e [irdma] [222808.419733] dosysdeletemodule.constprop.0+0x1e2/0x310 [222808.419745] x64sysdeletemodule+0x1b/0x30 [222808.419755] dosyscall64+0x39/0x90 [222808.419763] entrySYSCALL64afterhwframe+0x63/0xcd

[222808.419829] value changed: 0x01 -> 0x03

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

media: tuners: qt1010: replace BUGON with a regular error

BUGON is unnecessary here, and in addition it confuses smatch. Replacing this with an error return help resolve this smatch warning:

drivers/media/tuners/qt1010.c:350 qt1010init() error: buffer overflow 'i2cdata' 34 <= 34

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

of: overlay: fix null pointer dereferencing in finddupcsetnodeentry() and finddupcsetprop()

When kmalloc() fail to allocate memory in kasprintf(), fn1 or fn2 will be NULL, and strcmp() will cause null pointer dereference.

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

wifi: ath11k: Fix memory leak in ath11kpeerrxfragsetup

cryptoallocshash() allocates resources, which should be released by cryptofreeshash(). When ath11kpeerfind() fails, there has memory leak. Add missing cryptofreeshash() to fix this.