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

nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page

nvmetexecutediscgetlogpage() validates only the dword alignment of the host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmetcopytosgl(), which memcpy()s datalen bytes out to the host with no source-side bound check:

u64 offset = nvmetgetlogpageoffset(req->cmd); / 64-bit host / sizet datalen = nvmetgetlogpagelen(req->cmd); / 32-bit host / ... if (offset & 0x3) { ... } / only check / ... alloclen = sizeof(hdr) + entrysize discoverylogentries(req); buffer = kzalloc(alloclen, GFPKERNEL); ... status = nvmetcopytosgl(req, 0, buffer + offset, datalen);

The Discovery controller is unauthenticated -- nvmethostallowed() returns true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any TCP/RDMA/FC peer that can reach the nvmet target. With a discovery log page of ~1 KiB, an attacker requesting up to 4 KiB starting at offset == alloclen reads the next slab page out and gets its content returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical kernel pointers in one Get Log Page response). Pointing the offset at unmapped kernel memory faults the in-kernel memcpy and crashes (or panics, on paniconoops=1) the target host instead.

The attacker-controlled source-side offset pattern "nvmetcopytosgl(req, 0, buffer + ATTACKEROFFSET, ...)" is unique to nvmetexecutediscgetlogpage in the entire nvmet codebase: every other Get Log Page handler in admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local destination offset with a fixed source pointer.

Validate the host-supplied offset against the log page size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer buffer. The zero-fill matches the existing short-response pattern in nvmetexecutegetlogchangedns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains.

batman-adv: tpmeter: avoid use of uninit sender vars

batman-adv: fix tpmeter counter underflow during shutdown

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

RDMA/rxe: Validate pad and ICRC before payloadsize() in rxercv

rxercv() currently checks only that the incoming packet is at least headersize(pkt) bytes long before payloadsize() is used.

However, payloadsize() subtracts both the attacker-controlled BTH pad field and RXEICRCSIZE from pkt->paylen:

payloadsize = pkt->paylen - offset[RXEPAYLOAD] - bthpad(pkt) - RXEICRCSIZE

This means a short packet can still make payloadsize() underflow even if it includes enough bytes for the fixed headers. Simply requiring headersize(pkt) + RXEICRCSIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payloadsize() negative and pass an underflowed value to later receive-path users.

Fix this by validating pkt->paylen against the full minimum length required by payloadsize(): headersize(pkt) + bthpad(pkt) + RXEICRCSIZE.

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

btrfs: tracepoints: get correct superblock from dentry in event btrfssyncfile()

If overlay is used on top of btrfs, dentry->dsb translates to overlay's super block and fsid assignment will lead to a crash.

Use fileinode(file)->isb to always get btrfssb.

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

RDMA/iwcm: Fix use-after-free of work objects after cmid destruction

The commit 59c68ac31e15 ("iwcm: free cmid resources on the last deref") simplified cmid resource management by freeing cmid once all references to the cmid were removed. The references are removed either upon completion of iwcm event handlers or when the application destroys the cmid. This commit introduced the use-after-free condition where cmidprivate object could still be in use by event handler works during the destruction of cmid. The commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs") addressed this use-after- free by flushing all pending works at the cmid destruction.

However, still another use-after-free possibility remained. It happens with the work objects allocated for each cmidpriv within allocworkentries() during cmid creation, and subsequently freed in deallocworkentries() once all references to the cmid are removed. If the cmid's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below:

BUG: KASAN: slab-use-after-free in pwqactivatework+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091

CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iwcmwq) Call Trace: <TASK> dumpstacklvl+0x6a/0x90 printreport+0x174/0x554 ? virtaddrvalid+0x208/0x430 ? pwqactivatework+0x1ff/0x250 kasanreport+0xae/0x170 ? pwqactivatework+0x1ff/0x250 pwqactivatework+0x1ff/0x250 pwqdecnrinflight+0x8c5/0xfb0 processonework+0xc11/0x1460 ? pfxprocessonework+0x10/0x10 ? assignwork+0x16c/0x240 workerthread+0x5ef/0xfd0 ? pfxworkerthread+0x10/0x10 kthread+0x3b0/0x770 ? pfxkthread+0x10/0x10 ? rcuiswatching+0x11/0xb0 ? rawspinunlockirq+0x24/0x50 ? rcuiswatching+0x11/0xb0 ? pfxkthread+0x10/0x10 retfromfork+0x30/0x70 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 147416: kasansavestack+0x2c/0x50 kasansavetrack+0x10/0x30 kasankmalloc+0xa6/0xb0 allocworkentries+0xa9/0x260 [iwcm] iwcmconnect+0x23/0x4a0 [iwcm] rdmaconnectlocked+0xbfd/0x1920 [rdmacm] nvmerdmacmhandler+0x8e5/0x1b60 [nvmerdma] cmacmeventhandler+0xae/0x320 [rdmacm] cmaworkhandler+0x106/0x1b0 [rdmacm] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30

Freed by task 147091: kasansavestack+0x2c/0x50 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x60 kasanslabfree+0x4b/0x70 kfree+0x13a/0x4b0 deallocworkentries+0x125/0x1f0 [iwcm] iwcmderefid+0x6f/0xa0 [iwcm] cmworkhandler+0x136/0x1ba0 [iwcm] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30

Last potentially related work creation: kasansavestack+0x2c/0x50 kasanrecordauxstack+0xa3/0xb0 queuework+0x2ff/0x1390 queueworkon+0x67/0xc0 cmeventhandler+0x46a/0x820 [iwcm] siwcmupcall+0x330/0x650 [siw] siwcmworkhandler+0x6b9/0x2b20 [siw] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30

This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver.

To avoid the use-after-free of cmidprivate work objects, ensure that the last reference to the cmid is decremented not in the event handler works, but in the cmid destruction context. For that purpose, mo ---truncated---

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

nvmet: avoid potential UAF in nvmetreqcomplete()

An nvme target ->queueresponse() operation implementation may free the request passed as argument. Such implementation potentially could result in a use after free of the request pointer when percpurefput() is called in nvmetreqcomplete().

Avoid such problem by using a local variable to save the sq pointer before calling nvmetreqcomplete(), thus avoiding dereferencing the req pointer after that function call.

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

RDMA/iwcm: Fix a use-after-free related to destroying CM IDs

iwconnreqhandler() associates a new struct rdmaidprivate (connid) with an existing struct iwcmid (cmid) as follows:

connid->cmid.iw = cmid; cmid->context = connid; cmid->cmhandler = cmaiwhandler;

rdmadestroyid() frees both the cmid and the struct rdmaidprivate. Make sure that cmworkhandler() does not trigger a use-after-free by only freeing of the struct rdmaidprivate after all pending work has finished.

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

tipc: improve size validations for received domain records

The function tipcmonrcv() allows a node to receive and process domainrecord structs from peer nodes to track their views of the network topology.

This patch verifies that the number of members in a received domain record does not exceed the limit defined by MAXMONDOMAIN, something that may otherwise lead to a stack overflow.

tipcmonrcv() is called from the function tipclinkprotorcv(), where we are reading a 32 bit message data length field into a uint16. To avert any risk of bit overflow, we add an extra sanity check for this in that function. We cannot see that happen with the current code, but future designers being unaware of this risk, may introduce it by allowing delivery of very large (> 64k) sk buffers from the bearer layer. This potential problem was identified by Eric Dumazet.

This fixes CVE-2022-0435

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

nvmet: fix a use-after-free

Fix the following use-after-free complaint triggered by blktests nvme/004:

BUG: KASAN: user-memory-access in blkmqcompleterequestremote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvmeloopexecutework [nvmeloop] Call Trace: showstack+0x52/0x58 dumpstacklvl+0x49/0x5e printreport.cold+0x36/0x1e2 kasanreport+0xb9/0xf0 asanload4+0x6b/0x80 blkmqcompleterequestremote+0xac/0x350 nvmeloopqueueresponse+0x1df/0x275 [nvmeloop] nvmetreqcomplete+0x132/0x4f0 [nvmet] nvmetreqcomplete+0x15/0x40 [nvmet] nvmetexecuteioconnect+0x18a/0x1f0 [nvmet] nvmeloopexecutework+0x20/0x30 [nvmeloop] processonework+0x56e/0xa70 workerthread+0x2d1/0x640 kthread+0x183/0x1c0 retfromfork+0x1f/0x30

A remote stack overflow in the TIPC networking module. With FORTIFYSOURCE's stricter memcpy() bounds checking, this can be exploited to cause remote DOS via kernel panic on systems using TIPC. Prior to these bounds checks, and with a canary leak (or no CONFIGSTACKPROTECTOR), this can be exploited for RCE.

Reference: https://www.openwall.com/lists/oss-security/2022/02/10/1

In the Linux kernel before 4.9.6, there is an off by one in the drivers/mtd/spi-nor/cadence-quadspi.c cqspisetupflash() function. There are CQSPIMAXCHIPSELECT elements in the ->fpdata array so the ">" should be ">=" instead.