In the Linux kernel, the following vulnerability has been resolved:
crypto: krb5 - use kfreesensitive() for derived key buffers
cryptokrb5prepareencryption() and cryptokrb5preparechecksum() free the buffer holding the freshly derived keys with plain kfree(), leaving the key material behind in the freed slab object.
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: vsie: zero stale crypto bits
When shadowing crypto access bits from a format0 apcb (crycb 0 or 1), the bits 64..255 are unchanged from whatever is in the vsie page in the crycb and thus in the apcb. This gives a nested guest potential access to a device no longer available. Zero out the remaining bits.
Bluetooth: ISO: fix use-after-free of listener socket in isoconnready
CommServe contained a path traversal issue affecting information disclosure. Software customers upgrade to resolved maintenance release. Update CommServe.
CommServe contained a stack-based buffer overflow issue affecting service availability. Software customers upgrade to resolved maintenance release. Update CommServe.
CommServe contained an authentication bypass issue affecting access authorization and information disclosure. Software customers upgrade to resolved maintenance release. Update CommServe.
CommServe contained a heap-based buffer overflow issue affecting service availability. Software customers upgrade to resolved maintenance release. Update CommServe.
CommServe contained a cryptographic signature verification issue affecting privilege management. Software customers upgrade to resolved maintenance release. Update CommServe and Web Server.
In the Linux kernel, the following vulnerability has been resolved:
Input: psxpad-spi - set driver data before use
psxpadspisuspend() retrieves the controller state with spigetdrvdata(), but probe never stores it, so suspend dereferences a NULL pointer. Store it during probe.
In the Linux kernel, the following vulnerability has been resolved:
pmdomain: mediatek: mfg: initialize prevo in mtkmfgattachdev()
mtkmfgattachdev() reads prevo on the first iteration of its loop, in "if (prevo && prevo->freq == o->freq)", before prevo is assigned at the end of the loop body. On that first iteration, evaluating prevo reads an indeterminate value. If it is non-NULL, the condition dereferences a stale or invalid pointer, potentially faulting or incorrectly skipping the first OPP.
Initialize prevo to NULL. This matches the intent as well: there is no previous OPP to compare against on the first iteration.
Found with Clang's -Wconditional-uninitialized.
In the Linux kernel, the following vulnerability has been resolved:
pmdomain: mediatek: fix remaining %pOF after ofnodeput()
scpsysgetbusprotectionlegacy() looks up several legacy bus protection regmaps from device-tree nodes.
Two error paths put the device node before checking whether the regmap lookup failed, but still pass that node to deverrprobe() with %pOF on failure. If ofnodeput() drops the last reference, the later %pOF formatting can dereference a freed device node.
Keep the node reference until after the error message has been emitted in the infracfg and SMI lookup paths. Also drop the SMI node before returning when the SMI phandle is missing.
In the Linux kernel, the following vulnerability has been resolved:
regulator: fp9931: Fix VPOS/VNEG voltage selector table
The VPOSNEGtable[] mapping does not match the FP9931 datasheet.
The datasheet defines the VPOS/VNEG voltage mapping as:
00h-04h -> 7.04V (-7.04V) 05h -> 7.26V (-7.26V) 06h -> 7.49V (-7.49V) ... 28h-3Fh -> 15.06V (-15.06V)
However, VPOSNEGtable[] has two issues:
1. Selector 0x00~0x04 should all map to 7.04V (5 entries), but the table has 6 entries of 7.04V, causing all subsequent entries to be shifted by one position.
2. Selectors 0x29~0x3F should all clamp to 15.06V (23 entries), but the table has only 41 entries. Any selector value above 0x28 would result in an out-of-bounds table access.
Fix both issues by removing the duplicate 7.04V entry and appending the missing 23 clamped 15.06V entries, bringing the table to the correct size of 64 entries (0x00~0x3F).
In the Linux kernel, the following vulnerability has been resolved:
drm/log: Fix out-of-bounds read on empty message length
drmlogdrawkmsgrecord() accesses s[len - 1] to strip the trailing newline, but len is unsigned int. If len is 0, the subtraction wraps to UINTMAX, causing an out-of-bounds read.
Add an early return when len is 0.
bpf: Check skstate before skprotocol in bpftcpsyncookie
In the Linux kernel, the following vulnerability has been resolved:
ovpn: ensure socket is owned by ovpn before deref skuserdata
Some subsystems, like BPF SOCKMAP, set skuserdata without actually setting the encaptype.
For this reason, we must make sure that the type is the one ovpn expects before dereferencing skuserdata.
Failing to do so may lead to out-of-bounds reads.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: initialize inode mapping flags for cached inodes
[BUG] When running generic/795 with 8K block size, 4K page size, the test always fails, triggering some ASSERT()s related to folio size:
795 (241074): dropcaches: 3 assertion failed: ISALIGNED(start, blocksize) && ISALIGNED(end + 1, blocksize), in extentio.c:1404 (blocksize=8192 root=262 ino=258 start=16826368 end=16830463 mapping min order=0) ------------[ cut here ]------------ kernel BUG at extentio.c:1404! Oops: invalid opcode: 0000 [#1] SMP CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245 Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:assertfoliorange.cold+0x3d/0x3f [btrfs] Call Trace: <TASK> btrfsreadfolio+0x9e/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] prepareonefolio.constprop.0+0x104/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfsbufferedwrite+0x285/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfsdowriteiter+0x1aa/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] iterfilesplicewrite+0x31a/0x540 directspliceactor+0x53/0x170 splicedirecttoactor+0xe9/0x240 dosplicedirect+0x76/0xb0 vfscopyfilerange+0x1fd/0x630 x64syscopyfilerange+0xf9/0x220 dosyscall64+0xe1/0x790 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---
The ASSERT() itself is added by a later patch. The crash is triggered with that new debug patch, and without this fix.
[CAUSE] In the above case, the start 16826368 is properly 8K aligned, but the end (16830463 + 1) is not 8K aligned. Furthermore the mapping's minimal folio order is 0, not the expected 1 for 8K block size with 4K page size.
So this means some inodes do not have btrfssetinodemappingorder() called on it.
The missing btrfssetinodemappingorder() call happens for cached inodes, through the following events:
- btrfscreatenewinode() called for inode X Which properly sets minimal folio order for the VFS inode.
- btrfsupdateinode() called for inode X Which calls btrfsdelayedupdateinode() to create a delayednode into root->delayednodes xarray.
- Drop cache/memory pressure, evicting in-memory inode X Which evicted the inode X, but delayednode is still in root->delayednodes for future reuse.
- btrfsiget() for inode X called again
btrfsiget() |- btrfsigetlocked() | |- iget5lockedrcu() | Which creates a new vfsinode for btrfs, whose mapping still | has the minimal order as 0. | |- btrfsreadlockedinode() |- btrfsfillinode() | |- btrfsgetdelayednode() | Which found out the previous node, and use that delayed | node to initialize the new inode. | |- filled = true; |- if (filled) goto cacheindex; Which skips the btrfsupdateinodemappingflags() and btrfssetinodemappingorder() calls. So the inode still has minimal folio order set as 0, not the required 1.
Thus later page cache read will get a folio whose size is smaller than block size, as the mapping has its minimal folio order set as 0 not 1, then trigger the ASSERT().
[FIX] Move the btrfsupdateinodemappingflags() and btrfssetinodemappingorder() calls under cacheindex label, so that the mapping flags and minimal folio order is always set no matter if we have a cached inode.
ata: patasl82c105: fix bridge revision use-after-free
In the Linux kernel, the following vulnerability has been resolved:
net: remove CAPSYSRAWIO zero-padding in devvalidateheader
devvalidateheader() reads dev->hardheaderlen directly when zero-padding short link layer headers for CAPSYSRAWIO holders:
if (capable(CAPSYSRAWIO)) { memset(llheader + len, 0, dev->hardheaderlen - len); return true; }
Packet send paths call devvalidateheader() on skbs whose headroom was allocated from an earlier hardheaderlen read. If the device is reconfigured so that dev->hardheaderlen increases before validation, the memset writes past the reserved buffer, an out-of-bounds write.
This out-of-bounds write is masked in some SOCKRAW paths today because the same concurrent increase can first make skbpush() exceed the reserved headroom and trigger skbunderpanic(). Remove the zero-padding branch before making those hardheaderlen reads consistent, so the snapshot fixes do not turn a loud panic into a silent overwrite.
This path is only reached for variable length L2 protocols, where len < hardheaderlen but len >= minheaderlen. No remaining in-tree variable length L2 protocol implements headerops->validate, and the CAPSYSRAWIO bypass that zero-pads and accepts short headers has no real value beyond allowing testing of intentionally malformed input.
Drop the CAPSYSRAWIO branch. The remaining reads of dev->hardheaderlen in devvalidateheader() are comparisons only and have no memory safety impact.
IBM Langflow OSS 1.0.0 through 1.10.2 could allow a remote authenticated attacker to obtain sensitive information and inject messages into workflow history due to improper authorization.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: validate individual TWT params before driver setup
ieee80211processrxtwtaction() only partially validates a received S1G TWT setup frame before queueing it.
An individual agreement can therefore reach ieee80211s1grxtwtsetup() with twt->length too short for the full struct ieee80211twtparams.
The individual path passes twt to drvaddtwtsetup(). Both the tracepoint and the driver callback consume the complete parameters block, not merely reqtype. Do not pass a short individual agreement to the driver. Broadcast agreements remain unchanged because they are rejected locally after accessing only reqtype.
[edit commit message to not overclaim lack of validation nor understate driver impact]
In the Linux kernel, the following vulnerability has been resolved:
iomap: add a separate bioset for iomapsplitioend
iomapsplitioend can split bios that already come from iomapioendbioset and thus deadlock when the bioset is exhausted.
Add a separate bioset to avoid this deadlock.
Christian Brauner <brauner@kernel.org> says: Mark iomapioendsplitbioset static as it is only used in ioend.c, fixing the sparse warning reported by the kernel test robot.
In the Linux kernel, the following vulnerability has been resolved:
mm/percpu-km: fix bitmap overflow and accounting in pcpucreatechunk()
In pcpucreatechunk(), nrpages is the total contiguous backing allocation, i.e., nrunits pcpuunitpages, but pcpuchunkpopulated() uses it to set chunk->populated, whose size is pcpuunitpages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nrunits > 1, the function writes beyond chunk->populated. Fix it by using chunk->nrpages.
It also fixes the global pcpunremptypoppages accounting, since pcpubalancefree() only iterates up to chunk->nrpages.
Commit a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") introduced the bitmap overflow issue. Later, commit b539b87fed37f ("percpu: implmeent pcpunremptypoppages and chunk->nrpopulated") added pcpunremptypoppages and caused the accounting issue.
In the Linux kernel, the following vulnerability has been resolved:
sctp: validate Adaptation Indication parameter length
The Adaptation Layer Indication parameter contains a fixed 32-bit Adaptation Code Point after its parameter header. However, sctpverifyparam() accepts a header-only parameter because the generic parameter walker only requires the header to be present.
sctpprocessparam() then reads adaptationind beyond the declared parameter. When the malformed parameter is last in an INIT, the read starts at the receive skb tail, and the value is copied into the state cookie returned in the INIT ACK. This may disclose four receive-buffer tail bytes.
Require the declared parameter length to match the fixed structure size and abort the association through the existing invalid parameter length path otherwise.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: wake linked drain waiters on unlink
sndpcmdrain() on a linked stream parks an on-stack wait entry on the drained peer's runtime->sleep, and after scheduletimeout() removes it only if that peer is still found in the caller's group. If group membership changes during the wait and the sleep ends by signal or timeout (so autoremovewakefunction() does not run), finishwait() is skipped and sndpcmdrain() returns with the entry still queued on that stream's sleep list; a later wakeup() then walks a freed stack frame. This is reachable by unlinking either the drained or the draining stream.
Unlike the close path (sndpcmdrop() -> sndpcmpoststop()), sndpcmunlink() never wakes the sleep queues. Wake every group member under the group lock before the membership change, so a linked drainer is released and drops its entry while the streams are still grouped.
The window was opened when sndpcmlinkrwsem stopped being held across the wait and the removal became conditional on group membership (see Fixes). The later switch to finishwait() kept that conditional removal, so the signal/timeout case remained.
In the Linux kernel, the following vulnerability has been resolved:
iouring: preserve task restrictions across exec
Per-task restrictions apply to all rings created by a task. Once installed, they should not be dropped across exec.
For a task that has used iouring, the exec cancellation path calls iouringfree(). This frees both the task context and the per-task restriction, so a ring created after exec is unrestricted.
Split task context cleanup into iouringfreetctx(), and use it from the exec cancellation path. Keep iouringfree() for final task cleanup, where both the context and restriction are released.
In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: Fix undersized format-check buffer
fmtbuffersize in dasdeckdcheckdeviceformat() is declared as int, even though one of the multiplicands, sizeof(struct eckdcount), is a sizet. The expression
trkcount rptmax sizeof(struct eckdcount)
is therefore correctly evaluated at 64-bit width, but the result is silently truncated when it is stored back into the 32-bit fmtbuffersize variable. For a sufficiently large track range (startunit/stopunit are caller-controlled) this truncation yields a buffer size far smaller than the number of tracks actually requested. kzalloc() then succeeds with an undersized allocation, while the subsequent channel program build still operates on the untruncated track count and writes past the end of that buffer.
Compute the buffer size with checkmuloverflow() and keep it in a sizet, so that a value that no longer fits results in -EINVAL instead of a silently truncated allocation size.
In the Linux kernel, the following vulnerability has been resolved:
s390/zcrypt: Fix missing mem scrub at clear key import in ccaclr2cipherkey()
The helper function ipcprbhelper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory.
Extend the ipcprbhelper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not.
Extend the clear key to secure key token import process in function ccaclr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data.
Add explicit scrubbing on return from function ccaclr2cipherkey() for the random EXOR buffer and the cprb buffer.
Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed.
can: softing: fwparse(): validate firmware record spans
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: validate external BO copy bounds for both stride paths
vmwexternalbocopy() trusts caller-supplied offsets, strides, and heights and operates on imported dma-buf vmaps:
- The equal-stride memcpy() bound was clamped after subtracting the offsets from dstsize and srcsize; an offset larger than the BO size wraps the unsigned subtraction to a huge value and the resulting memcpy() runs off the end of the vmap. dststride height is also a u32 multiplication that can overflow. - The non-equal-stride row-by-row path had no bound at all. The loop touches bytes through offset + (height - 1) stride + widthinbytes, with only a WARNON(dststride < widthinbytes), and could likewise step past the end of either mapping.
The offsets and strides are derived from STDU/SOU plane state, so a configured CRTC submitting a crafted atomic commit on an imported framebuffer can reach this path.
Validate the exact row-copy endpoint against each BO's size up front using checkmuloverflow() and checkaddoverflow(). Use the bulk memcpy() path only when widthinbytes covers the whole stride; otherwise copy one row at a time so partial-row updates near the bottom of a framebuffer remain valid. Also reject zero strides and stride < widthinbytes, both of which the row-by-row path cannot represent safely.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hcisync: hold conn in hciconnectacl/lesync() callbacks
There is theoretical UAF if the conn is freed while the hcisync task is running.
Hold refcount to avoid that.