A vulnerability was found in Linux Kernel, where a type confusion problem in checkmapfunccompatibility() may lead to free arbitrary kernel memory.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=5b029a32cfe4600f5e10e36b41778506b90fd4de https://www.zerodayinitiative.com/advisories/ZDI-21-1148/

A flaw was found within the parsing of SMB2 requests that have a transform header in the kernel ksmbd module. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this to disclose sensitive information on affected installations of Linux. Only systems with ksmbd enabled are vulnerable to this CVE.

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

ksmbd: fix null pointer dereference in allocpreauthhash()

The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauthinfo is not allocated. This patch add KSMBDSESSNEEDSETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete.

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

nvme: skip the zoned limits update if the zone info query failed

nvmequeryzoneinfo() returns either a negative errno or a positive NVMe status code, but nvmeupdatensinfoblock() only tests for the negative case:

ret = nvmequeryzoneinfo(ns, lbaf, &zi); if (ret < 0) goto out;

If the device fails the Identify Namespace (I/O Command Set specific) command, or the Identify Controller command issued by nvmesetmaxappend(), the positive status falls through and setup continues with the zero-initialized zone info. nvmeupdatezoneinfo() then marks the queue zoned with chunksectors and ns->head->zsze set to zero.

blkvalidatezonedlimits() does not check chunksectors, so the limits commit succeeds. blkrevalidatediskzones() does reject the zero zone size, but by then the limits are live and nothing rolls them back, so I/O keeps being submitted to a zoned queue with a zero zone size and diskzoneno() shifts by ilog2(0):

nvme0n1: Invalid non power of two zone size (0) UBSAN: shift-out-of-bounds in include/linux/blkdev.h:747:16 shift exponent -1 is negative diskzoneno include/linux/blkdev.h:747 [inline] biostraddleszones include/linux/blkdev.h:1058 [inline] blkzonewplughandlewrite block/blk-zoned.c:1423 [inline] blkzoneplugbio.cold+0x25/0x1c8 block/blk-zoned.c:1605 blkmqsubmitbio+0x18fb/0x2870 block/blk-mq.c:3196 submitbhwbc+0x575/0x740 fs/buffer.c:2824 blockwritefullfolio+0x728/0xdd0 fs/buffer.c:1933

Any device, firmware or NVMe-oF target that fails this one command reaches this.

Skip the zoned limits update in that case, and log which of the two things happened: during a revalidation the queue keeps the zone geometry it was last validated with, and on a first scan the namespace is registered without zoned limits, so that it is still available as a handle for admin commands. Neither of the paths in nvmequeryzoneinfo() that return a positive status logs anything, so the failure would otherwise be silent.

zi.zonesize is an exact indicator: every path that returns a positive status returns before it is assigned, and after that the only failure left is -ENODEV, which the caller already handles.

Found by FuzzNvme.

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

staging: rtl8723bs: fix OOB read in rtwrestructwmmie()

rtwrestructwmmie() scans inie for a WMM IE with:

while (i < inlen) { ... if (i + 5 < inlen && inie[i] == 0xDD && ...) { ... break; } i += (inie[i + 1] + 2); / to the next IE element / }

When the "i + 5 < inlen" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of inie), execution falls through to "i += (inie[i + 1] + 2)", which reads inie[i + 1]. If i == inlen - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data.

Commit a75281626fc8f ("staging: rtl8723bs: fix potential out-of-bounds read in rtwrestructwmmie") added the "i + 5 < inlen" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path.

Add an explicit bounds check before advancing to the next IE.

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

mmc: via-sdmmc: cancel card-detect work on remove

Disabling the device interrupt and freeing the IRQ prevents new card-detect work from being queued, but carddetwork already queued by the handler can still run after viasdremove() returns. viasdccarddetect() recovers the host through containerof() and dereferences its MMIO base; once remove() returns the host can be freed, so that work would touch freed memory.

Cancel carddetwork after freeing the IRQ and before cancelling finishbhwork, which the card-detect handler can also queue. carddetwork can re-enable the interrupt through viaresetpcictrl(); mask it again afterwards.

This issue was found by an in-house static analysis tool and confirmed by manual code review.

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

libceph: Reject monmaps advertising zero monitors

A message of type CEPHMSGMONMAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in opensession(). This happens because the "BUGON(monc->monmap->nummon < 1)" assertion in picknewmon() is triggered.

This patch extends a check in cephmonmapdecode() to also reject arriving monmaps with nummon == 0 rather than only with nummon > CEPHMAXMON.

[ idryomov: drop "log output for unusual values of nummon" part ]

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

eventpoll: don't decrement ep refcount while still holding the ep mutex

Jann Horn points out that epoll is decrementing the ep refcount and then doing a

mutexunlock(&ep->mtx);

afterwards. That's very wrong, because it can lead to a use-after-free.

That pattern is actually fine for the very last reference, because the code in question will delay the actual call to "epfree(ep)" until after it has unlocked the mutex.

But it's wrong for the much subtler "next to last" case when somebody else may also be dropping their reference and free the ep while we're still using the mutex.

Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion.

A mutex "unlock" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up.

See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics:

"mutexunlock() may access the mutex structure even after it has internally released the lock already - so it's not safe for another context to acquire the mutex and assume that the mutexunlock() context is not using the structure anymore"

So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops their reference and releases the 'ep' as it now has no users - all while the mutexunlock() is still accessing it.

Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole point of refcounts: unlike mutexes, they are inherently about object lifetimes).

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

scsi: hisisas: Grab sasdev lock when traversing the members of sasdev.list

When freeing slots in function slotcompletev3hw(), it is possible that sasdev.list is being traversed elsewhere, and it may trigger a NULL pointer exception, such as follows:

==>cq thread ==>scsieh6

==>scsierrorhandler() ==>sasehhandlesaserrors() ==>sasscsifindtask() ==>llddaborttask() ==>slotcompletev3hw() ==>hisisasaborttask() ==>hisisasslottaskfree() ==>deregdevicev3hw() ==>listdelinit() ==>listforeachentrysafe()

[ 7165.434918] sas: Enter sasscsirecoverhost busy: 32 failed: 32 [ 7165.434926] sas: trying to find task 0x00000000769b5ba5 [ 7165.434927] sas: sasscsifindtask: aborting task 0x00000000769b5ba5 [ 7165.434940] hisisasv3hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted [ 7165.434964] hisisasv3hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored [ 7165.434965] hisisasv3hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored [ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 7165.434972] hisisasv3hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored [ 7165.434975] hisisasv3hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored [ 7165.434976] Mem abort info: [ 7165.434982] ESR = 0x96000004 [ 7165.434991] Exception class = DABT (current EL), IL = 32 bits [ 7165.434992] SET = 0, FnV = 0 [ 7165.434993] EA = 0, S1PTW = 0 [ 7165.434994] Data abort info: [ 7165.434994] ISV = 0, ISS = 0x00000004 [ 7165.434995] CM = 0, WnR = 0 [ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2 [ 7165.434998] [0000000000000000] pgd=0000000000000000 [ 7165.435003] Internal error: Oops: 96000004 [#1] SMP [ 7165.439863] Process scsieh6 (pid: 4109, stack limit = 0x00000000c43818d5) [ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO) [ 7165.473637] pc : deregdevicev3hw+0x68/0xa8 [hisisasv3hw] [ 7165.479443] lr : deregdevicev3hw+0x2c/0xa8 [hisisasv3hw] [ 7165.485247] sp : ffff00001d623bc0 [ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508 [ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8 [ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8 [ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00 [ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8 [ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff [ 7165.520276] x17: 0000000000000000 x16: 0000000000000000 [ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8 [ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067 [ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0 [ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00 [ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00 [ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e [ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000 [ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e [ 7165.567872] Call trace: [ 7165.570309] deregdevicev3hw+0x68/0xa8 [hisisasv3hw] [ 7165.575775] hisisasaborttask+0x248/0x358 [hisisasmain] [ 7165.581415] sasehhandlesaserrors+0x258/0x8e0 [libsas] [ 7165.586876] sasscsirecoverhost+0x134/0x458 [libsas] [ 7165.592082] scsierrorhandler+0xb4/0x488 [ 7165.596163] kthread+0x134/0x138 [ 7165.599380] retfromfork+0x10/0x18 [ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021) [ 7165.609004] kernel fault(0x1) notification starting on CPU 75 [ 7165.700728] ---[ end trace fc042cbbea224efc ]--- [ 7165.705326] Kernel panic - not syncing: Fatal exception

To fix the issue, grab sasdev lock when traversing the members of sasdev.list in deregdevicev3hw() and hisisasreleasetasks() to avoid concurrency of adding and deleting member. When ---truncated---

btrfs: don't check PageError in extentwritepage

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

iomap: iomap: fix memory corruption when recording errors during writeback

Every now and then I see this crash on arm64:

Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dmthinpool dmpersistentdata XFS (dm-0): Metadata I/O Error (0x1) detected at xfstransreadbufmap+0x1ec/0x590 [xfs] (fs/xfs/xfstransbuf.c:296). dmbioprison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfsimaplookup: xfsiallocreadagi() returned error -5, agno 0 dmbufio dmlogwrites xfs nftchainnat xtREDIRECT nfnat nfconntrack nfdefragipv6 nfdefragipv4 ip6tREJECT potentially unexpected fatal signal 6. nfrejectipv6 potentially unexpected fatal signal 6. iptREJECT nfrejectipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsecgsskrb5 authrpcgss xttcpudp ipsethaship ipsethashnet xtset nftcompat ipsethashmac ipset nftables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) iptables pc : 000003fd6d7df200 xtables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wbworkfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseqset+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : filemapsetwberr+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000

x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseqset+0x1c/0x100 filemapsetwberr+0x24/0xe0 iomapdowritepage+0x5e4/0xd5c writecachepages+0x208/0x674 iomapwritepages+0x34/0x60 xfsvmwritepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---

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

accel/rocket: fix UAF via dangling GEM handle in createbo

rocketioctlcreatebo() inserts a GEM handle into the file's IDR via drmgemhandlecreate() early on, then performs several operations that can fail (sgt allocation, drmmm insert, iommumap). If any fail after the handle is live, the error path calls drmgemshmemobjectfree() which kfree's the object without removing the handle from the IDR.

This leaves a dangling handle pointing to freed slab memory. Any subsequent ioctl using that handle (PREPBO, FINIBO, SUBMIT) calls drmgemobjectlookup() and dereferences freed memory (UAF).

Fix by moving drmgemhandlecreate() to after all fallible operations succeed, matching the pattern used by panfrost, lima, and etnaviv.

Also fix drmmminsertnodegeneric() whose return value was silently overwritten by iommumapsgtable() on the next line. Add the missing error check.

[tomeu: Move handle creation to the very end]

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

net: mana: Skip redundant detach on already-detached port

When manaperportqueueresetworkhandler() runs after a previous detach succeeded but attach failed, the port is left in a detached state with apc->txqp and apc->rxqs already freed. Calling manadetach() again unconditionally leads to NULL pointer dereferences during queue teardown.

Add an early exit in manadetach() when the port is already in detached state (!netifdevicepresent) for non-close callers, making it safe to call idempotently. This allows the queue reset handler and other recovery paths to simply retry manaattach() without redundant teardown.

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

vsock/virtio: bind uarg before filling zerocopy skb

virtiotransportsendpktinfo() allocates or reuses the zerocopy uarg before entering the send loop, but virtiotransportallocskb() still fills the skb before it inherits that uarg. When fixed-buffer vectored zerocopy hits MAXSKBFRAGS, iosgfromiter() may partially attach managed frags and return -EMSGSIZE. The rollback path call kfreeskb() to free an skb that carries SKBFLMANAGEDFRAGREFS but no uarg, so skbreleasedata() falls through to ordinary frag unref.

Pass the uarg into virtiotransportallocskb() and bind it immediately before virtiotransportfillskb(). This keeps control or no-payload skbs untouched while ensuring success and rollback share one lifetime rule.

A flaw was found within the parsing of extended attributes in the kernel ksmbd module. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this to disclose sensitive information on affected installations of Linux. Only systems with ksmbd enabled are vulnerable to this CVE.

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

net/smc: free stashed qentry before overwrite in REQADDLINK to ADDLINK transition

When smcllceventhandler() transitions the local LLC flow from SMCLLCFLOWREQADDLINK to SMCLLCFLOWADDLINK on arrival of an ADDLINK request, it calls smcllcflowqentryset() unconditionally:

if (lgr->llcflowlcl.type == SMCLLCFLOWREQADDLINK) { lgr->llcflowlcl.type = SMCLLCFLOWADDLINK; smcllcflowqentryset(&lgr->llcflowlcl, qentry); ... }

A CONFIRMLINK or ADDLINKCONT arriving while flow->type is SMCLLCFLOWREQADDLINK is stashed into flow->qentry via the SMCLLCCONFIRMLINK / SMCLLCADDLINKCONT handler (which stores into flow->qentry for any non-NONE flow type). When the subsequent ADDLINK arrives, the REQADDLINK branch overwrites flow->qentry with the new pointer without first freeing the stashed allocation, leaking one kmalloc object.

The stashed entry has no consumer: smcllcwait() is only called from llcaddlinkwork, which is not yet scheduled while the flow type remains REQADDLINK. No waiter is sleeping on llcmsgwaiter at this point. It is safe to unconditionally free any stashed qentry before the overwrite.

Call smcllcflowqentrydel() before smcllcflowqentryset() in the REQADDLINK branch. smcllcflowqentrydel() already checks flow->qentry before freeing, so the normal path where no entry is stashed is a no-op.

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

nilfs2: prevent out-of-bounds read in super root block parsing

super-root inode metadata size is trusted before nilfsreadinodecommon().

Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfsreadinodecommon() read past the end of the super-root block.

[ryusuke: clarify the commit title]

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

mtd: rawnand: validate ONFI extended parameter page sections

nandflashdetectextparampage() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation.

Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfiexteccinfo. Use device-scoped diagnostics that identify the malformed ONFI section.

f2fs: use the mount idmap for the owner check in f2fsxattradviseset()

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

wifi: iwlwifi: mei: check SAP message length before reading it

Verify the SAP message size is not larger than the local buffer before reading the message to avoid buffer overflow.

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

powerpc/mm: fix wrong addrpfn tracking in compound vmemmap population

vmemmappopulatecompoundpages() uses addrpfn to determine the PFN offset within a compound page and to decide whether the current vmemmap slot should be populated as a head page mapping or should reuse a tail page mapping.

However, addrpfn is advanced manually in parallel with addr. The loop itself progresses in vmemmap address space, so each PAGESIZE step in addr covers PAGESIZE / sizeof(struct page) struct page slots. Since addrpfn is compared against nrpages in data-PFN units, it should advance by the same number of PFNs. The existing manual increments do not match that and therefore do not reliably track the PFN corresponding to the current addr.

As a result, pfnoffset can be computed from the wrong PFN and the code can make the head/tail decision for the wrong compound-page position.

Fix this by deriving addrpfn directly from the current vmemmap address instead of carrying it as loop state.

drm/msm/dsi: Drop devpmoppsetrate(0)

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

s390/vfio-ap: Fix control domain removal in vfioapmdevcfgremove

The vfioapconfigremove function uses the bitmapandnot function to clear bits from the matrixmdev->matrix.adm bitmap (specifies the control domains assigned to the mdev). This prevents the explicitly unplugged control domains from being removed the KVM guest. The bitmapand function is used instead.

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

media: rc: sunxi-cir: Unregister rc device on probe failure

After rcregisterdevice() succeeds, later probe failures must undo the registration with rcunregisterdevice(). The current error path jumps to the allocation cleanup label and only calls rcfreedevice(), leaving the rc device registration and resources created by rcregisterdevice() behind.

Add a registered-device unwind label for the IRQ lookup, IRQ request, and hardware initialization failure paths. Keep rcfreedevice() for failures before rcregisterdevice() succeeds.

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

scsi: qla2xxx: Zero mailbox struct in qla2x00getfirmwarestate()

The mbxcmdt is allocated on the stack but left uninitialized. qla2x00mailboxcommand() has several early-return paths (PCI permanent failure, device failed, EEH busy, ISP abort pending, mailbox access timeout, purge mbox) that return without writing the input mailbox registers back into mcp->mb[]. qla2x00getfirmwarestate() then unconditionally copies mcp->mb[1..6] (and mb[12]) into the caller's states[] array regardless of the return value.

On such a failure the copied values are uninitialized kernel stack memory, which is then exposed to userspace via the fwstate and mpifwstate sysfs handlers. Zero the mailbox struct so a failed query yields deterministic zeroed state instead of leaking stack contents.

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

nullblk: register configfs subsystem after creating default devices

In nullinit(), configfsregistersubsystem() currently runs before registerblkdev(), so when nullblk is built as a module, a racing mkdir() + poweron from userspace can reach nulladddev() while nullmajor is still 0. adddisk() then hits WARNON(disk->minors) (major=0 with minors!=0) and fails:

[root@fedora ~]# [ 2366.521436] WARNING: block/genhd.c:476 at adddisk+0x8a7/0xde0, [ 2366.523552] Modules linked in: nullblk(+) nftfibinet nftfibipv4 nftfibipv6 nftfib [ 2366.529081] CPU: 26 UID: 0 PID: 1600 Comm: sh Not tainted 7.2.0-rc1+ #66 PREEMPT(full) ...... [ 2366.547251] Call Trace: [ 2366.547575] <TASK> [ 2366.547831] ? rawspinlock+0x84/0xe0 [ 2366.548260] adddiskfwnode+0x114/0x560 [ 2366.548739] nulladddev+0x102d/0x1b80 [nullblk] [ 2366.549310] ? pfxnulladddev+0x10/0x10 [nullblk] [ 2366.549906] ? mutexlock+0xde/0x1c0 [ 2366.550361] ? pfxmutexlock+0x10/0x10 [ 2366.550827] nullbdevicepowerstore+0x1e7/0x280 [nullblk] [ 2366.551499] ? pfxnullbdevicepowerstore+0x10/0x10 [nullblk] [ 2366.552177] ? kmalloccachenoprof+0x1f5/0x470 [ 2366.552748] ? configfswriteiter+0x35c/0x4e0 [ 2366.553242] configfswriteiter+0x286/0x4e0 [ 2366.553787] vfswrite+0x52d/0xd00 [ 2366.554169] ? pfxvfswrite+0x10/0x10 [ 2366.554679] ? pfxcssrstatupdated+0x10/0x10 [ 2366.555196] ? fdgetpos+0x1cf/0x4c0 [ 2366.555649] ksyswrite+0xfc/0x1d0 ......

Additionally, the errdev path destroys all devices on nullblist while configfs is still registered. If a racing mkdir() + poweron puts a user device on the list, nulldestroydev()->nullfreedev() kfrees the user device's nullbdevice but /sys/kernel/config/nullb/<name> is still reachable. Any userspace access to the item will trigger a UAF.

For simplicity, move configfsregistersubsystem() to the end to solve the problems above.

fat: release buffer head after rebuilding parent

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

wifi: iwlwifi: mvm: fix off-by-one in TXF key sanitiser

iwlmvmfrobtxfkeyiter() tracks the last matched byte position in loop variable 'i'. When a full key match is found (match == keylen), 'i' points at the last byte of the matched key. The memset start offset should therefore be i + 1 - keylen, not i - keylen; the current code zeroes one byte before the match and leaves the final key byte un-sanitised.

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

s390/vfio-ap: fix stale pqaphook pointer on error in vfioapmdevsetkvm()

In vfioapmdevsetkvm(), kvm->arch.crypto.pqaphook is set to &matrixmdev->pqaphook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqaphook pointing at the failing matrixmdev instead of the mdev that legitimately owns the KVM.

Since matrixmdev->kvm is never set on this error path, vfioapmdevunsetkvm() will not clean up the hook when matrixmdev is later closed. If matrixmdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqaphookrwsem, resulting in a use-after-free.

Since kvm->arch.crypto.pqaphook is only set in the vfioapmdevsetkvm() function and is cleared in the vfioapmdevunsetkvm() function, a check for 'kvm->arch.crypto.pqaphook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrixdev->mdevlist list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevslock while iterating the list; however, this did not prevent a potential race condition.

The pqaphookrwsem(write) is now performed inside getupdatelocksforkvm(), which is updated to acquire pqaphookrwsem(write) between kvm->lock and mdevslock. This ordering is consistent with the PQAP intercept path, which acquires pqaphookrwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqaphookrwsem(read).

The pqaphookrwsem is now released inside the releaseupdatelocksforkvm(), which is updated to release pqaphookrwsem(write) between mdevslock and kvm->lock.

Additionally, kvmputkvm() in vfioapmdevunsetkvm() is moved after releaseupdatelocksforkvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvmdestroyvm() would run under kvm->lock, which would deadlock.

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

libceph: validate banner payload length

When parsing the Ceph messenger v2 protocol banner, the payloadlen field is decoded from the banner prefix. If a client sends a banner with a payloadlen of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in populateiniter():

------------[ cut here ]------------ !iovitercount(&con->v2.initer) WARNING: net/ceph/messengerv2.c:3129 at populateiniter net/ceph/messengerv2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messengerv2.c:3129 at cephconv2tryread+0x6634/0x6810 net/ceph/messengerv2.c:3159, CPU#1: kworker/1:3/5070 ... Call Trace: <TASK> cephconworkfn+0x1f5/0x14a0 net/ceph/messenger.c:1575 processonework kernel/workqueue.c:3322 [inline] processscheduledworks+0xa8e/0x14e0 kernel/workqueue.c:3405 workerthread+0xa47/0xfb0 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 retfromfork+0x514/0xb70 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

According to the msgr2 protocol specification, the banner payload is expected to contain at least two 64-bit integers (serverfeat and serverreqfeat). Therefore, payloadlen must be at least 16 bytes.

Fix this by adding a check in processbannerprefix() to reject a payloadlen smaller than 16 bytes. This prevents the 0-length read and correctly aborts the connection with a protocol error.