In the Linux kernel, the following vulnerability has been resolved:
nvmet-fc: avoid scheduling association deletion twice
When forcefully shutting down a port via the configfs interface, nvmetportsubsysdroplink() first calls nvmetportdelctrls() and then nvmetdisableport(). Both functions will eventually schedule all remaining associations for deletion.
The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion.
Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.
In the Linux kernel, the following vulnerability has been resolved:
libceph: prevent potential out-of-bounds writes in handleauthsessionkey()
The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets.
[ idryomov: changelog ]
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to detect potential corrupted nid in freenidlist
As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let's add sanity check on f2fsallocnid() to detect any potential corruption in freenidlist.
In the Linux kernel, the following vulnerability has been resolved:
veth: reduce XDP nodirect return section to fix race
As explain in commit fa349e396e48 ("veth: Fix race with AFXDP exposing old or uninitialized descriptors") for veth there is a chance after napicompletedone() that another CPU can manage start another NAPI instance running vethpool(). For NAPI this is correctly handled as the napischeduleprep() check will prevent multiple instances from getting scheduled, but for the remaining code in vethpool() this can run concurrent with the newly started NAPI instance.
The problem/race is that xdpclearreturnframenodirect() isn't designed to be nested.
Prior to commit 401cb7dae813 ("net: Reference bpfredirectinfo via taskstruct on PREEMPTRT.") the temporary BPF net context bpfredirectinfo was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' taskstruct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent vethpool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context.
Race is when another CPU gets within the xdpsetreturnframenodirect() section before exiting vethpool() calls the clear-function xdpclearreturnframenodirect().
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix double free of qgroup record after failure to add delayed ref head
In the previous code it was possible to incur into a double kfree() scenario when calling adddelayedrefhead(). This could happen if the record was reported to already exist in the btrfsqgrouptraceextentnolock() call, but then there was an error later on adddelayedrefhead(). In this case, since adddelayedrefhead() returned an error, the caller went to free the record. Since adddelayedrefhead() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee.
The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the adddelayedrefhead(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecordinsertedret' boolean to account for this. Hence, the caller has to kfree the object only if adddelayedrefhead() reports not to have inserted it on the tracing logic.
As a side-effect of the above, we must guarantee that 'qrecordinsertedret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecordinsertedret' having an invalid value on an early exit.
The documentation from the adddelayedrefhead() has also been updated to reflect on the exact ownership of the 'qrecord' object.
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Clear cmds after chip reset
Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") caused two problems:
1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.
2. BUGON(cmd->sgmapped) in qltfreecmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qltunmapsg() at the same time: BUGON(!validdmadirection(dir)) in dmaunmapsgattrs().
So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and partially revert "scsi: qla2xxx: target: Fix offline port handling and host reset handling" at qla2x00abortallcmds.
In the Linux kernel, the following vulnerability has been resolved:
ixgbe: Fix panic during XDPTX with > 64 CPUs
Commit 4fe815850bdc ("ixgbe: let the xdpdrv work with more than 64 cpus") adds support to allow XDP programs to run on systems with more than 64 CPUs by locking the XDP TX rings and indexing them using cpu % 64 (IXGBEMAXXDPQS).
Upon trying this out patch on a system with more than 64 cores, the kernel paniced with an array-index-out-of-bounds at the return in ixgbedeterminexdpring in ixgbe.h, which means ixgbedeterminexdpqidx was just returning the cpu instead of cpu % IXGBEMAXXDPQS. An example splat:
========================================================================== UBSAN: array-index-out-of-bounds in /var/lib/dkms/ixgbe/5.18.6+focal-1/build/src/ixgbe.h:1147:26 index 65 is out of range for type 'ixgbering [64]' ========================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000058 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 65 PID: 408 Comm: ksoftirqd/65 Tainted: G IOE 5.15.0-48-generic #54~20.04.1-Ubuntu Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.5.4 01/13/2020 RIP: 0010:ixgbexmitxdpring+0x1b/0x1c0 [ixgbe] Code: 3b 52 d4 cf e9 42 f2 ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 b9 00 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 <44> 0f b7 47 58 0f b7 47 5a 0f b7 57 54 44 0f b7 76 08 66 41 39 c0 RSP: 0018:ffffbc3fcd88fcb0 EFLAGS: 00010282 RAX: ffff92a253260980 RBX: ffffbc3fe68b00a0 RCX: 0000000000000000 RDX: ffff928b5f659000 RSI: ffff928b5f659000 RDI: 0000000000000000 RBP: ffffbc3fcd88fce0 R08: ffff92b9dfc20580 R09: 0000000000000001 R10: 3d3d3d3d3d3d3d3d R11: 3d3d3d3d3d3d3d3d R12: 0000000000000000 R13: ffff928b2f0fa8c0 R14: ffff928b9be20050 R15: 000000000000003c FS: 0000000000000000(0000) GS:ffff92b9dfc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 000000011dd6a002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ixgbepoll+0x103e/0x1280 [ixgbe] ? schedclockcpu+0x12/0xe0 napipoll+0x30/0x160 netrxaction+0x11c/0x270 dosoftirq+0xda/0x2ee runksoftirqd+0x2f/0x50 smpbootthreadfn+0xb7/0x150 ? sortrange+0x30/0x30 kthread+0x127/0x150 ? setkthreadstruct+0x50/0x50 retfromfork+0x1f/0x30 </TASK>
I think this is how it happens:
Upon loading the first XDP program on a system with more than 64 CPUs, ixgbexdplockingkey is incremented in ixgbexdpsetup. However, immediately after this, the rings are reconfigured by ixgbesetuptc. ixgbesetuptc calls ixgbeclearinterruptscheme which calls ixgbefreeqvectors which calls ixgbefreeqvector in a loop. ixgbefreeqvector decrements ixgbexdplockingkey once per call if it is non-zero. Commenting out the decrement in ixgbefreeqvector stopped my system from panicing.
I suspect to make the original patch work, I would need to load an XDP program and then replace it in order to get ixgbexdplockingkey back above 0 since ixgbesetuptc is only called when transitioning between XDP and non-XDP ring configurations, while ixgbexdplockingkey is incremented every time ixgbexdpsetup is called.
Also, ixgbesetuptc can be called via ethtool --set-channels, so this becomes another path to decrement ixgbexdplockingkey to 0 on systems with more than 64 CPUs.
Since ixgbexdplockingkey only protects the XDPTX path and is tied to the number of CPUs present, there is no reason to disable it upon unloading an XDP program. To avoid confusion, I have moved enabling ixgbexdplockingkey into ixgbeswinit, which is part of the probe path.
In the Linux kernel, the following vulnerability has been resolved:
iomap: adjust read range correctly for non-block-aligned positions
iomapadjustreadrange() assumes that the position and length passed in are block-aligned. This is not always the case however, as shown in the syzbot generated case for erofs. This causes too many bytes to be skipped for uptodate blocks, which results in returning the incorrect position and length to read in. If all the blocks are uptodate, this underflows length and returns a position beyond the folio.
Fix the calculation to also take into account the block offset when calculating how many bytes can be skipped for uptodate blocks.
In the Linux kernel, the following vulnerability has been resolved:
libceph: prevent potential out-of-bounds reads in handleauthdone()
Perform an explicit bounds check on payloadlen to avoid a possible out-of-bounds access in the callout.
[ idryomov: changelog ]
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: add bounds checks in nvmettcpbuildpduiovec
nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to copytoiter() GPF/KASAN. Guard sgidx, remaining entries, and sg->length/offset before building the bvec.
e1000: fix OOB in e1000tbishouldaccept()
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential UAF in smb2closecachedfid()
findorcreatecacheddir() could grab a new reference after krefput() had seen the refcount drop to zero but before cfidlistlock is acquired in smb2closecachedfid(), leading to use-after-free.
Switch to krefputlock() so cfidrelease() is called with cfidlistlock held, closing that gap.
In the Linux kernel, the following vulnerability has been resolved:
drm/gpusvm: fix hmmpfntomaporder() usage
Handle the case where the hmm range partially covers a huge page (like 2M), otherwise we can potentially end up doing something nasty like mapping memory which is outside the range, and maybe not even mapped by the mm. Fix is based on the xe userptr code, which in a future patch will directly use gpusvm, so needs alignment here.
v2: - Add kernel-doc (Matt B) - s/fls/ilog2/ (Thomas)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: use lock accessing portstate and rport state
nvmefcunregisterremote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvmefccreateassociation is not taking a lock to check the portstate and atomically increase the active count on the rport.
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Cache streams targeting link when performing LT automation
[WHY] Last LT automation update can cause crash by referencing currentstate and calling into dcupdateplanesandstream which may clobber currentstate.
[HOW] Cache relevant stream pointers and iterate through them instead of relying on the currentstate.
In the Linux kernel, the following vulnerability has been resolved:
landlock: Fix handling of disconnected directories
Disconnected files or directories can appear when they are visible and opened from a bind mount, but have been renamed or moved from the source of the bind mount in a way that makes them inaccessible from the mount point (i.e. out of scope).
Previously, access rights tied to files or directories opened through a disconnected directory were collected by walking the related hierarchy down to the root of the filesystem, without taking into account the mount point because it couldn't be found. This could lead to inconsistent access results, potential access right widening, and hard-to-debug renames, especially since such paths cannot be printed.
For a sandboxed task to create a disconnected directory, it needs to have write access (i.e. FSMAKEREG, FSREMOVEFILE, and FSREFER) to the underlying source of the bind mount, and read access to the related mount point. Because a sandboxed task cannot acquire more access rights than those defined by its Landlock domain, this could lead to inconsistent access rights due to missing permissions that should be inherited from the mount point hierarchy, while inheriting permissions from the filesystem hierarchy hidden by this mount point instead.
Landlock now handles files and directories opened from disconnected directories by taking into account the filesystem hierarchy when the mount point is not found in the hierarchy walk, and also always taking into account the mount point from which these disconnected directories were opened. This ensures that a rename is not allowed if it would widen access rights [1].
The rationale is that, even if disconnected hierarchies might not be visible or accessible to a sandboxed task, relying on the collected access rights from them improves the guarantee that access rights will not be widened during a rename because of the access right comparison between the source and the destination (see LANDLOCKACCESSFSREFER). It may look like this would grant more access on disconnected files and directories, but the security policies are always enforced for all the evaluated hierarchies. This new behavior should be less surprising to users and safer from an access control perspective.
Remove a wrong WARNONONCE() canary in collectdomainaccesses() and fix the related comment.
Because opened files have their access rights stored in the related file security properties, there is no impact for disconnected or unlinked files.
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: pv: fix index value of replaced ASCE
The index field of the struct page corresponding to a guest ASCE should be 0. When replacing the ASCE in s390replaceasce(), the index of the new ASCE should also be set to 0.
Having the wrong index might lead to the wrong addresses being passed around when notifying pte invalidations, and eventually to validity intercepts (VM crash) if the prefix gets unmapped and the notifier gets called with the wrong address.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix race condition in hidpsessionthread
There is a potential race condition in hidpsessionthread that may lead to use-after-free. For instance, the timer is active while hidpdeltimer is called in hidpsessionthread(). After hidpsessionput, then 'session' will be freed, causing kernel panic when hidpidletimeout is running.
The solution is to use deltimersync instead of deltimer.
Here is the call trace:
? hidpsessionprobe+0x780/0x780 calltimerfn+0x2d/0x1e0 runtimers.part.0+0x569/0x940 hidpsessionprobe+0x780/0x780 calltimerfn+0x1e0/0x1e0 ktimeget+0x5c/0xf0 lapicnextdeadline+0x2c/0x40 clockeventsprogramevent+0x205/0x320 runtimersoftirq+0xa9/0x1b0 dosoftirq+0x1b9/0x641 irqexitrcu+0xdc/0x190 irqexitrcu+0xe/0x20 sysvecapictimerinterrupt+0xa1/0xc0
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix potential user-after-free
This fixes all instances of which requires to allocate a buffer calling allocskb which may release the chan lock and reacquire later which makes it possible that the chan is disconnected in the meantime.
In the Linux kernel, the following vulnerability has been resolved:
net/smc: use smclgrlist.lock to protect smclgrlist.list iterate in smcrportadd
While doing smcrportadd, there maybe linkgroup add into or delete from smclgrlist.list at the same time, which may result kernel crash. So, use smclgrlist.lock to protect smclgrlist.list iterate in smcrportadd.
The crash calltrace show below: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: G Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014 Workqueue: events smcibporteventwork [smc] RIP: 0010:smcrportadd+0xa6/0xf0 [smc] RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297 RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918 R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4 R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08 FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0 PKRU: 55555554 Call Trace: smcibporteventwork+0x18f/0x380 [smc] processonework+0x19b/0x340 workerthread+0x30/0x370 ? processonework+0x340/0x340 kthread+0x114/0x130 ? kthreadcancelwork+0x50/0x50 retfromfork+0x1f/0x30
In the Linux kernel, the following vulnerability has been resolved:
iommu/sva: invalidate stale IOTLB entries for kernel address space
Introduce a new IOMMU interface to flush IOTLB paging cache entries for the CPU kernel address space. This interface is invoked from the x86 architecture code that manages combined user and kernel page tables, specifically before any kernel page table page is freed and reused.
This addresses the main issue with vfree() which is a common occurrence and can be triggered by unprivileged users. While this resolves the primary problem, it doesn't address some extremely rare case related to memory unplug of memory that was present as reserved memory at boot, which cannot be triggered by unprivileged users. The discussion can be found at the link below.
Enable SVA on x86 architecture since the IOMMU can now receive notification to flush the paging cache before freeing the CPU kernel page table pages.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: split cachedfid bitfields to avoid shared-byte RMW races
isopen, haslease and onlist are stored in the same bitfield byte in struct cachedfid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. orb $mask, addr on x8664), so updating one flag can restore stale values of the others.
A possible interleaving is: CPU1: load old byte (haslease=1, onlist=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | ISOPEN) -> reintroduces cleared bits
To avoid this class of races, convert these flags to separate bool fields.
SolarEdge SE3680H ships with an outdated Linux kernel containing unpatched vulnerabilities in core subsystems. An attacker with network or local access can exploit these flaws to achieve remote code execution, privilege escalation, or disclosure of sensitive information.
In the Linux kernel, the following vulnerability has been resolved:
erofs: validate the extent length for uncompressed pclusters
syzkaller reported a KASAN use-after-free: https://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2
The referenced fuzzed image actually has two issues: - mpa == 0 as a non-inlined pcluster; - The logical length is longer than its physical length.
The first issue has already been addressed. This patch addresses the second issue by checking the extent length validity.
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: Correctly handle Rx checksum offload errors
The stmmacrx function would previously set skb->ipsummed to CHECKSUMUNNECESSARY if hardware checksum offload (CoE) was enabled and the packet was of a known IP ethertype.
However, this logic failed to check if the hardware had actually reported a checksum error. The hardware status, indicating a header or payload checksum failure, was being ignored at this stage. This could cause corrupt packets to be passed up the network stack as valid.
This patch corrects the logic by checking the csumnone status flag, which is set when the hardware reports a checksum error. If this flag is set, skb->ipsummed is now correctly set to CHECKSUMNONE, ensuring the kernel's network stack will perform its own validation and properly handle the corrupt packet.
In the Linux kernel, the following vulnerability has been resolved:
hungtask: fix warnings caused by unaligned lock pointers
The blocker tracking mechanism assumes that lock pointers are at least 4-byte aligned to use their lower bits for type encoding.
However, as reported by Eero Tamminen, some architectures like m68k only guarantee 2-byte alignment of 32-bit values. This breaks the assumption and causes two related WARNONONCE checks to trigger.
To fix this, the runtime checks are adjusted to silently ignore any lock that is not 4-byte aligned, effectively disabling the feature in such cases and avoiding the related warnings.
Thanks to Geert Uytterhoeven for bisecting!
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix invalid free of JFSIP(ipimap)->iimap in diUnmount
syzbot found an invalid-free in diUnmount:
BUG: KASAN: double-free in slabfree mm/slub.c:3661 [inline] BUG: KASAN: double-free in kmemcachefree+0x71/0x110 mm/slub.c:3674 Free of addr ffff88806f410000 by task syz-executor131/3632
CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1b1/0x28e lib/dumpstack.c:106 printaddressdescription+0x74/0x340 mm/kasan/report.c:284 printreport+0x107/0x1f0 mm/kasan/report.c:395 kasanreportinvalidfree+0xac/0xd0 mm/kasan/report.c:460 kasanslabfree+0xfb/0x120 kasanslabfree include/linux/kasan.h:177 [inline] slabfreehook mm/slub.c:1724 [inline] slabfreefreelisthook+0x12e/0x1a0 mm/slub.c:1750 slabfree mm/slub.c:3661 [inline] kmemcachefree+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfsimap.c:195 jfsumount+0x108/0x370 fs/jfs/jfsumount.c:63 jfsputsuper+0x86/0x190 fs/jfs/super.c:194 genericshutdownsuper+0x130/0x310 fs/super.c:492 killblocksuper+0x79/0xd0 fs/super.c:1428 deactivatelockedsuper+0xa7/0xf0 fs/super.c:332 cleanupmnt+0x494/0x520 fs/namespace.c:1186 taskworkrun+0x243/0x300 kernel/taskwork.c:179 exittaskwork include/linux/taskwork.h:38 [inline] doexit+0x664/0x2070 kernel/exit.c:820 dogroupexit+0x1fd/0x2b0 kernel/exit.c:950 dosysexitgroup kernel/exit.c:961 [inline] sesysexitgroup kernel/exit.c:959 [inline] x64sysexitgroup+0x3b/0x40 kernel/exit.c:959 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd [...]
JFSIP(ipimap)->iimap is not setting to NULL after free in diUnmount. If jfsremount() free JFSIP(ipimap)->iimap but then failed at diMount(). JFSIP(ipimap)->iimap will be freed once again. Fix this problem by setting JFSIP(ipimap)->iimap to NULL after free.
drm/vmwgfx: Validate command header size against SVGACMDMAXDATASIZE
Bluetooth: MGMT: cancel mesh send timer when hdev removed
Bluetooth: btusb: reorder cleanup in btusbdisconnect to avoid UAF