A vulnerability was found in the Linux kernel in versions prior to v5.14-rc1. Missing size validations on inbound SCTP packets may allow the kernel to read uninitialized memory.
An issue was discovered in the Linux kernel before 5.7.3, related to mm/gup.c and mm/hugememory.c. The getuserpages (aka gup) implementation, when used for a copy-on-write page, does not properly consider the semantics of read operations and therefore can grant unintended write access, aka CID-17839856fd58.
IBM Engineering Requirements Management Doors Next 7.0.2, 7.0.3, and 7.1
could allow an authenticated user on the network to delete comments from other users due to client-side enforcement of server-side security.
IBM Engineering Requirements Management Doors Next 7.0.2, 7.0.3, and 7.1 could allow an authenticated user on the network to delete reviews from other users due to client-side enforcement of server-side security.
DoS Vulnerability in wolfSSL TLS 1.3 CKS Extension
Chromium: CVE-2025-11219 Use after free in V8
A flaw was found in the kernel's audit by access permission feature which would not record openbyhandleat syscalls.
This does not mean that a user is granted access to resources that they would not be able to. This means that the audit log trail would not contain the log events of access.
A vulnerability in the Linux kernel's keyrings garbage collector allowing any local user account to trigger a kernel panic.
Problem arrises when using requestkey() or keyctl request2.
This code sequence tries to invoke an upcall to instantiate a keyring if one doesn't already exist by that name within the user's keyring set. However, if the upcall fails, the code sets keyring->typedata.rejecterror to -ENOKEY or some other error code. When the key is garbage collected, the key destroy function is called unconditionally and keyringdestroy() uses listempty() on keyring->typedata.link - which is in a union with rejecterror. Subsequently, the kernel tries to unlink the keyring from the keyring names list, which leads to an oops.
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix response queue over-consumption in qlaconsumeiocb()
qla24xxprocessresponsequeue() advances ringptr past the head IOCB before dispatching, so by the time qlaconsumeiocb() runs, ringptr already points at the first continuation IOCB. The function however looped purex->entrycount times starting at ringptr. As entrycount includes the head, this consumed one entry too many: it stamped RESPONSEPROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked.
Mark the head processed and account for it, then consume only the entrycount - 1 continuation IOCBs, matching qlacopypurextobuffer().
Bluetooth: hcicore: use skbget() instead of skbclone() for reqskb
In the Linux kernel, the following vulnerability has been resolved:
RDMA/efa: Fix PBL chunk length computation
On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFAPTRSPERCHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length.
If the PBL number of pages is a multiple of EFAPTRSPERCHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration.
Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFAPTRSPERCHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario.
In the Linux kernel, the following vulnerability has been resolved:
signal: avoid shared siginfo namespace rewrites
sendsignallocked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next.
Copy the siginfo before changing it.
In the Linux kernel, the following vulnerability has been resolved:
of: fix out-of-bounds read in ofaliasscan() stem parser
The stem parser tests isdigit((end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first.
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix skb leak on flow key update failure during ct
ovsctexecute() always steals or frees the skb on failure while ovsflowkeyupdate() does not. So, if it fails and we return right away, the skb ends up leaked.
Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly.
This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless.
Reported by Sashiko.
Bluetooth: btintel: Validate length before parsing diagnostics TLV
drm/amdkfd: fix QID bit leak in pqmcreatequeue()
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix socket refcount leak in smcswitchconns()
smcswitchconns() takes a reference on the SMC socket before dropping lgr->connslock, so the connection stays alive while the CDC slot is fetched:
sockhold(&smc->sk); readunlockbh(&lgr->connslock); / pre-fetch buffer outside of sendlock, might sleep / rc = smccdcgetfreeslot(conn, tolnk, &wrbuf, NULL, &pend); if (rc) goto errout;
The errout label only drops the wrtx link reference, so this early exit returns without the matching sockput(). The second error exit is not affected, because sockput() has already run by then.
A leaked skrefcnt means the smcsock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down.
smccdcgetfreeslot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smcswitchconns() run in the first place.
Restructure so there is a single sockput() covering both outcomes, instead of adding a second one to the error path.
In the Linux kernel, the following vulnerability has been resolved:
vt: add permission check for KDSKBMETA ioctl
KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vtkioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization.
ima: fix out-of-bounds read in xattrverify()
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix qentry overwrite for CONFIRMLINK and ADDLINKCONT in smcllceventhandler()
The SMCLLCCONFIRMLINK / SMCLLCADDLINKCONT branch in smcllceventhandler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRMLINK or ADDLINKCONT request while a flow is active and flow->qentry is already set, smcllcflowqentryset() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message.
The sibling SMCLLCDELETELINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRMLINK/ADDLINKCONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation.
The response direction (smcllcrxresponse()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.
In the Linux kernel, the following vulnerability has been resolved:
Input: evdev - fix information leak in evdevpassvalues()
In evdevpassvalues(), the inputevent structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct inputevent contains explicit or implicit padding (such as the 32-bit pad field on SPARC64), these padding bytes are left uninitialized.
When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information.
Similar issues exist in evdevqueuesyndropped and passevent.
Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary.
In the Linux kernel, the following vulnerability has been resolved:
ipip: fix skb leak in collectmd mode when metadatadst allocation fails
In collectmd mode ipiptunnelrcv() returns 0 without freeing the skb when iptunrxdst() fails to allocate the metadatadst. ipiprcv() and mplsiprcv() are registered as xfrmtunnel handlers, so tunnel4rcv() and tunnelmpls4rcv() read the zero return as "the packet has been consumed" and do not free it either. The skb is leaked.
The other tunnel drivers all dispose of the packet at this point: ip6tunnel.c jumps to its drop label, ipgre.c and ip6gre.c return PACKETREJECT, which makes grercv() free the skb. Only ipip returns 0.
Jump to the existing drop label instead. It frees the skb and still returns 0, so the packet keeps being reported as consumed, which is what we want here: the outer header has already been pulled, and neither the remaining handlers nor an ICMP unreachable have any use for it.
Triggering this needs an ipip or mplsip tunnel in collectmd mode and an atomic allocation failure, which is why it has gone unnoticed.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftablesoffload: suppress WARNONONCE for ENOMEM in abort path
In nftflowruleoffloadabort(), WARNONONCE(err) is triggered on every error during rollback, including -ENOMEM. Memory allocation failures are expected under low-memory conditions and do not indicate a kernel bug.
Trace for example: nftflowoffloadchain() // FLOWBLOCKBIND nftflowblockchain() nftchainoffloadcmd() nftblockoffloadcmd() ->ndosetuptc() nsimsetuptc() flowblockcbsetupsimple() flowblockcballoc() // fails to -ENOMEM
The warning was reproduced on the 5.10 stable kernel under memory pressure via fault injection, but the underlying bug exists in mainline as well, as demonstrated by the ENOMEM trace above. The following splat was triggered during nftables transaction processing:
WARNING: CPU: 0 PID: 8567 at net/netfilter/nftablesoffload.c:532 nftflowruleoffloadabort net/netfilter/nftablesoffload.c:532 [inline] WARNING: CPU: 0 PID: 8567 at net/netfilter/nftablesoffload.c:532 nftflowruleoffloadcommit+0x971/0xcd0 net/netfilter/nftablesoffload.c:591 Modules linked in: CPU: 0 PID: 8567 Comm: syz-executor.0 Not tainted 5.10.260-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:nftflowruleoffloadabort net/netfilter/nftablesoffload.c:532 [inline] RIP: 0010:nftflowruleoffloadcommit+0x971/0xcd0 net/netfilter/nftablesoffload.c:591 Call Trace: nftablescommit+0x3bd/0x4bd0 net/netfilter/nftablesapi.c:8604 nfnetlinkrcvbatch+0xb1e/0x1f20 net/netfilter/nfnetlink.c:509 nfnetlinkrcvskbbatch net/netfilter/nfnetlink.c:579 [inline] nfnetlinkrcv+0x3b3/0x420 net/netfilter/nfnetlink.c:597 netlinkunicastkernel net/netlink/afnetlink.c:1314 [inline] netlinkunicast+0x6cd/0xa00 net/netfilter/afnetlink.c:1340 netlinksendmsg+0x906/0xe10 net/netfilter/afnetlink.c:1919 socksendmsgnosec net/socket.c:651 [inline] socksendmsg+0x155/0x190 net/socket.c:663 syssendmsg+0x705/0x870 net/socket.c:2379 syssendmsg+0x100/0x170 net/socket.c:2433 syssendmsg+0xe9/0x1c0 net/socket.c:2462 dosyscall64+0x33/0x40 arch/x86/entry/common.c:46 entrySYSCALL64afterhwframe+0x67/0xd1
Change the condition to WARNONONCE(err && err != -ENOMEM) so that warnings are only emitted for unexpected errors. This aligns with the common kernel practice of not warning on -ENOMEM.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
HID: core: fix number/pointer type confusion on long items
In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: fix memory leak from alloc-during-teardown race
mptcppmdestroy() empties msk->pm.annolist and msk->pm.userspacepmlocaladdrlist under msk->pm.lock during socket teardown, dropping the lock between the two.
A concurrent userspace PM genl ANNOUNCE on the same msk holds a sock reference via mptcptokengetsock() and, in mptcppmnlannouncedoit(), calls mptcpuserspacepmappendnewlocaladdr() and mptcppmannouncedalloc(). Both take msk->pm.lock briefly to add to their respective lists. Because the genl handler holds a sock reference, mptcppmdestroy() may run on the same msk via mptcpdisconnect(), which invokes mptcpdestroycommon() without dropping the sock refcount, before the handler completes.
If the lock acquisitions interleave such that mptcppmdestroy() empties a list first, the later alloc adds its entry to a list head that nothing else iterates for this msk, and the entry leaks. kmemleak reports both mptcppmaddaddr objects (from mptcppmannouncedalloc()) and mptcppmaddrentry objects (from mptcpuserspacepmappendnewlocaladdr()) under sustained concurrent ANNOUNCE + close load against the userspace PM.
Add an MPTCPPMDESTROYING bit in msk->pm.status, set by mptcppmdestroy() under pm.lock before the lists are emptied and checked under pm.lock by the alloc paths. Either the alloc takes pm.lock first, in which case its entry is on the list when mptcppmdestroy() frees it; or mptcppmdestroy() takes pm.lock first, in which case the later alloc observes the bit and refuses.
Found by an MPTCP protocol-flow harness extending BRF (arXiv:2305.08782).
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: option: fix slab OOB read in interrupt URB callback
The interrupt URB buffer is allocated in setupportinterruptin() based on the endpoint's wMaxPacketSize:
buffersize = usbendpointmaxp(epd); port->interruptinbuffer = kmalloc(buffersize, GFPKERNEL);
When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes).
If the device sends a short packet (actuallength < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read:
data[sizeof(struct usbctrlrequest)]
which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read.
Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usbctrlrequest header before accessing reqpkt->bRequestType and reqpkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usbctrlrequest)] inside the conditional. Use sizeof(reqpkt) instead of sizeof(struct usbctrlrequest) for consistency.
[ johan: use deverr(); split signals declaration and initialisation ]
ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout
In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix xfrmstateconstruct() auth-trunc leak
attachauthtrunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadbalgid. One real case is cmac(aes).
xfrmstateconstruct() then treats !x->props.aalgo as "no auth algorithm attached yet" and calls attachauth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer.
Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.
HID: roccat: free buffered reports when destroying device
In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq25890: Fix powersupply reference leak
bq25890fwprobe() acquires a reference to a secondary charger using powersupplygetbyname(), but the reference is not released on later probe failures or on driver detach.
In particular, failures after bq25890fwprobe() returns successfully, such as a failure in bq25890hwinit(), also leak the reference.
Register a device-managed cleanup action immediately after acquiring the secondary charger. This releases the reference on all subsequent probe failures and on driver detach.
Found by code review.