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.

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 ]

e1000: fix OOB in e1000tbishouldaccept()

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:

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:

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:

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:

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:

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:

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:

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.