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

powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW

Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing.

These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range.

The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below

BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGESIZE=64K MMU=Hash SMP NRCPUS=2048 NUMA pSeries Modules linked in: afpacket rfkill ibmveth(X) lpfc(+) nvmetfc nvmet nvmekeyring crct10difvpmsum nvmefc nvmefabrics nvmecore be2net(+) nvmeauth rtcgeneric nfsd authrpcgss nfsacl lockd grace sunrpc fuse configfs iptables xtables xfs libcrc32c dmservicetime ibmvfc(X) scsitransportfc vmxcrypto gf128mul crc32cvpmsum dmmirror dmregionhash dmlog dmmultipath dmmod sdmod scsidhemc scsidhrdac scsidhalua t10pi crc64rocksoftgeneric crc64rocksoft sg crc64 scsimod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950149) hv:phyp pSeries Workqueue: events workforcpufn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommutablereservepages+0xac/0x100 LR [c00000000005e830] iommuinittable+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommuinittable+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommubypasssupportedpSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dmaiommudmasupported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dmasupported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dmasetmask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] beprobe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] localpciprobe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] workforcpufn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] processonework+0x314/0x620 [c00001400c9fff10] [c00000000018f280] workerthread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] startkernelthread+0x14/0x18

There are 2 issues in the code

1. The index is "int" while the address is "unsigned long". This results in negative value when setting the bitmap.

2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.

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

drm/panel/panel-sitronix-st7701: Remove panel on DSI attach failure

In case mipidsiattach() fails, call drmpanelremove() to avoid memory leak.

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

net: serialize netifrunning() check in enqueuetobacklog()

Syzbot reported a KASAN slab-use-after-free in fibruleslookup().

The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit).

Commit e9e4dd3267d0 ("net: do not process device backlog during unregistration") introduced a lockless netifrunning() check in enqueuetobacklog() to prevent queuing packets to an unregistering device.

However, this creates a TOCTOU race window.

A lockless transmitter (like vethxmit) can pass the check before devclose() clears IFFUP. If the transmitter is then delayed, flushallbacklogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed.

Fix this by moving the netifrunning() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netifrunning() after the flush/close completes (so it gets dropped).

Bluetooth: 6lowpan: avoid untracked enable work

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

drm/xe/vf: Add drmdev guards when detaching CCS read/write buffers

CCS read/write buffers are freed during BO destruction. In some cases, BOs may be destroyed after the device is unbound but while the DRM structure remains valid, leading to NULL pointer dereferences when accessing device resources.

BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 9376 Comm: xepat Not tainted 7.2.0-rc2+ #1 PREEMPT(lazy) RIP: 0010:xesriovvfccsrwupdatebbaddr+0x4d/0xa0 [xe] RSP: 0018:ffffcf304110b9c8 EFLAGS: 00010246 RAX: ffff8a85c38a0a00 RBX: 00000000810ef000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8a85c39c1888 RBP: ffffcf304110b9e8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a85c39c1888 R13: 0000000000000000 R14: ffff8a85c39b4f28 R15: ffff8a85c3885000 FS: 0000000000000000(0000) GS:ffff8a878b809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010314a002 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <TASK> xemigrateccsrwcopyclear+0x98/0x120 [xe] xesriovvfccsdetachbo+0x2c/0x60 [xe] xettmbodeletememnotify+0xc8/0xe0 [xe] ttmbocleanupmemtypeuse+0x26/0x80 [ttm] ttmborelease+0x29e/0x2d0 [ttm] ttmbofini+0x39/0x70 [ttm] xegemobjectfree+0x1f/0x30 [xe] drmgemobjectfree+0x1d/0x40 ttmbovmclose+0x5f/0x90 [ttm] removevma+0x2c/0x70 teardownvmas+0x63/0xf0 exitmmap+0x20d/0x3f0 mmput+0x45/0x170 mmput+0x31/0x40 doexit+0x2ba/0xac0 dogroupexit+0x2d/0xb0 x64sysexitgroup+0x18/0x20 x64syscall+0x14a0/0x2390 dosyscall64+0xdd/0x640 ? countmemcgevents+0xea/0x240 ? handlemmfault+0x1ec/0x2f0

(cherry picked from commit 1ae415a6eefe5004954a1d352b1718faca8844ef)

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

cachefiles: Fix error return when vfsmkdir() fails

When vfsmkdir() fails, the error code is not extracted from the returned error pointer. This causes mkdirerror to be reached with ret=0, which leads to returning ERRPTR(0) (NULL) instead of a proper error pointer.

Fix this by extracting the error code from the error pointer when vfsmkdir() fails.

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

netfilter: ebtables: terminate table name before findtablelock()

updatecounters() and compatupdatecounters() forward a user-supplied 32-byte table name to findtablelock() without NUL-terminating it. On a lookup miss, findinlistlock() calls trythenrequestmodule(..., "%s%s", "ebtable", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte.

BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) requestmodule (kernel/module/kmod.c:150) doupdatecounters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) updatecounters (net/bridge/netfilter/ebtables.c:1440) doebtsetctl (net/bridge/netfilter/ebtables.c:2573) nfsetsockopt (net/netfilter/nfsockopt.c:101) ipsetsockopt (net/ipv4/ipsockglue.c:1424) rawsetsockopt (net/ipv4/raw.c:847) syssetsockopt (net/socket.c:2393) ...

compatdoreplace() shares the same unterminated name via compatcopyebtreplacefromuser(); terminate it there too so all findtablelock() callers behave alike. The other callers already terminate the name after the copy.

ALSA: PCM: Fix wait queue list corruption in sndpcmdrain() on linked streams

ALSA: usb-audio: Avoid potential endless loop in convertchmapv3()

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

ipv4: icmp: validate reply type before using icmppointers

Extended echo replies use ICMPEXTECHOREPLY as the outbound reply type. That value is outside the range covered by icmppointers[], which only describes the traditional ICMP types up to NRICMPTYPES.

Avoid consulting icmppointers[] for reply types outside that range, and use arrayindexnospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.

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

HID: roccat: fix use-after-free in roccatreportevent

roccatreportevent() iterates over the device->readers list without holding the readerslock. This allows a concurrent roccatrelease() to remove and free a reader while it's still being accessed, leading to a use-after-free.

Protect the readers list traversal with the readerslock mutex.

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

wifi: brcmfmac: validate bsscfg indices in IF events

brcmffwehhandleifevent() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check.

Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array.

[add missing wifi prefix]

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

nfsd: Initialize ssc before laundromatwork to prevent NULL dereference

In nfs4statestartnet(), laundromatwork may access nfsdssc through nfs4laundromat -> nfsd4sscexpireumount. If nfsdssc isn't initialized, this can cause NULL pointer dereference.

Normally the delayed start of laundromatwork allows sufficient time for nfsdssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4statestartnet -> nfsd4endgrace -> nfsd4recordgracedone -> nfsd4cldgracedone -> cldpipeupcall -> cldpipeupcall -> waitforcompletion path), the delayed work may start before nfsdssc initialization finishes.

Fix this by moving nfsdssc initialization before starting laundromatwork.

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

ALSA: FCP: fix OOB write in fcpmeterctlget()

fcpioctlsetmetermap() bounds the user-supplied Level Meter map size by the driver's own limit of 255

if (map.mapsize < 1 || map.mapsize > 255 || map.meterslots < 1 || map.meterslots > 255) return -EINVAL;

and passes it to fcpaddnewctl() as the control's channel count, where it is stored as elem->channels.

Every control read writes into struct sndctlelemvalue, whose integer array is declared long value[128], so the limit is 128, not 255. fcpmeterctlget() stores one 64-bit word per channel into that array with no bound of its own:

for (i = 0; i < elem->channels; i++) { int idx = private->meterlevelmap[i]; int value = idx < 0 ? 0 : le32tocpu(resp[idx]);

ucontrol->value.integer.value[i] = value; }

sndctlelemreaduser() serves that object from memdupuser(control, sizeof(control)), 1224 bytes on LP64 out of kmalloc-2048. offsetof(struct sndctlelemvalue, value) is 72, so element i is written at byte 72 + 8 i and element 144 already lands past the allocation. At mapsize 255 the last store ends at byte 2112, 888 bytes past the object and 64 bytes into the adjacent slab object. The stored words come from the device and meterlevelmap[] selects which word lands in which slot, so extent and contents are both controlled.

The core does not catch this. sndctlcheckeleminfo() is reached only from sndctleleminfo(), which sndctlelemread() calls under CONFIGSNDCTLDEBUG; without that option sndctlskipvalidation() is a compile-time true. sndctladdreplace() validates kcontrol->count and never inspects elem->channels.

Installing an oversized map needs CAPSYSRAWIO, but the control outlives the hwdep descriptor that created it, so the out-of-bounds stores are issued by any process able to read controls on /dev/snd/controlC0.

KASAN on 7.2.0-rc5 (arm64), triggered by an unprivileged control read:

BUG: KASAN: slab-out-of-bounds in fcpmeterctlget Write of size 8 at addr ffff000017af04c8 by task fcptrigger/185 asanstore8 fcpmeterctlget sndctlelemread sndctlioctl Allocated by task 185: memdupuser sndctlioctl The buggy address is located 0 bytes to the right of allocated 1224-byte region [ffff000017af0000, ffff000017af04c8)

Bound the map size by the ABI limit rather than by 255, and bound the store loop at the sink so it cannot run past the value array whatever elem->channels holds.

Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

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

ALSA: seq: Serialize UMP output teardown with eventinput

sequmpprocessevent() borrows client->outrfile.output without synchronizing with the first-open and last-close transition in sequmpclientopen() and sequmpclientclose().

The last output unuse can therefore drop opened[STROUT] to zero and release the rawmidi file while an in-flight eventinput callback is still inside sndrawmidikernelwrite(). That leaves the rawmidi substream runtime exposed to teardown before the write path has taken its own buffer reference.

Add a per-client rwlock for the eventinput-visible output file. Publish a newly opened output file under the write side, and hold the read side from the output lookup through sndrawmidikernelwrite(). The last output close copies and clears the visible output file under the write side, then drops the lock and releases the saved rawmidi file. Use IRQ-safe rwlock guards because eventinput can also be reached from atomic sequencer delivery.

The buggy scenario involves two paths, with each column showing the order within that path:

path A label: eventinput path path B label: last unuse path 1. sequmpprocessevent() reads 1. sequmpclientclose() client->outrfile.output. drops opened[STROUT] to zero. 2. sndrawmidikernelwrite1() 2. sndrawmidikernelrelease() has not yet pinned runtime. closes the output file. 3. The writer continues using 3. closesubstream() frees the borrowed substream. substream->runtime.

This keeps the output substream and runtime alive for the full eventinput write while keeping rawmidi release outside the rwlock.

KASAN reproduced this as a slab-use-after-free in sndrawmidikernelwrite1(), with allocation through sequmpuse()/sndseqportconnect() and free through sequmpunuse()/sndseqportdisconnect().

Validation reproduced this kernel report: KASAN slab-use-after-free in sndrawmidikernelwrite1+0x9d/0x400 RIP: 0033:0x7f5528af837f Read of size 8 Call trace: dumpstacklvl+0x73/0xb0 (?:?) printreport+0xd1/0x650 (?:?) srsoaliasreturnthunk+0x5/0xfbef5 (?:?) virtaddrvalid+0x1a7/0x340 (?:?) kasancompletemodereportinfo+0x64/0x200 (?:?) kasanreport+0xf7/0x130 (?:?) sndrawmidikernelwrite1+0x9d/0x400 (?:?) asanload8+0x82/0xb0 (?:?) updatestackstate+0x1ef/0x2d0 (?:?) sndrawmidikernelwrite+0x1a/0x20 (?:?) sequmpprocessevent+0xd4/0x120 (sound/core/seq/sequmpclient.c:82) sndseqdeliversingleevent+0x8a/0xe0 (?:?) sndseqdeliverfromump+0x2b2/0xd60 (?:?) lockacquire+0x14e/0x2e0 (?:?) findheldlock+0x31/0x90 (?:?) sndseqportuseptr+0xa6/0xe0 (?:?) kasancheckwrite+0x18/0x20 (?:?) dorawreadunlock+0x32/0xa0 (?:?) rawreadunlock+0x26/0x50 (?:?) sndseqdeliversingleevent+0x45c/0x4b0 (?:?) sndseqdeliverevent+0x10d/0x1b0 (?:?) sndseqclientenqueueevent+0x192/0x240 (?:?) sndseqwrite+0x2cd/0x450 (?:?) apparmorfilepermission+0x20/0x30 (?:?) securityfilepermission+0x51/0x60 (?:?) vfswrite+0x1ce/0x850 (?:?) fgetfiles+0x12b/0x220 (?:?) lockrelease+0xc8/0x2a0 (?:?) rcureadunlock+0x74/0x2d0 (?:?) fgetfiles+0x135/0x220 (?:?) ksyswrite+0x15a/0x180 (?:?) rcuiswatching+0x24/0x60 (?:?) x64syswrite+0x46/0x60 (?:?) x64syscall+0x7d/0x20d0 (?:?) dosyscall64+0xc1/0x360 (arch/x86/entry/syscall64.c:87) entrySYSCALL64afterhwframe+0x77/0x7f (?:?)

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

power: supply: ab8500fg: fix use-after-free on remove

ab8500fgremove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue.

Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply externalpowerchanged callback) can requeue them.

Found by an in-house static analysis tool.

HID: wacom: validate report length in wacomintuospro2btirq

HID: rmi: fix OOB access with undersized RMI reports

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

Revert "media: v4l2-dev: fix error handling in videoregisterdevice()"

This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a.

The intentions of that patch were good, but it doesn't work.

The idea is that if deviceregister fails, you have to do a putdevice to let the ref counter release resources.

However, the V4L2 API says that if videoregisterdevice() fails, then you have to call videodevicerelease(), which kfree()s the videodevice struct.

But the putdevice() will already have freed the struct, so you end up in a double-free scenario.

There is not really a good way of fixing this without breaking videoregisterdevice() into two parts, one that initializes everything, and one that does the actual deviceregister, and then converting all V4L2 drivers to this new model.

That is a massive job, and it is very unlikely that deviceregister will fail.

So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.

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

mm/vmscan: report RCU-tasks quiescent states in shrinklruvec()

I am seeing some rcutasks stalls in the Meta fleet during reclaim.

INFO: rcutasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idlecpu: -1/8 task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrinklruvec memcgroupiter shrinknode dotrytofreepages trytofreepages allocfrozenpagesnoprof allocpagesnoprof pteallocone ptealloc handlemmfault

Nothing promises direct reclaim returns in bounded time, and the scan loop in shrinklruvec() only calls condresched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout.

Upgrade it to condreschedtasksrcuqs(), which reports a quiescent state even when condresched() does nothing.

PS: This has been discussed in [1]

i2c: imx: Fix slave registration race and error handling

Bluetooth: mgmt: fix UAF in pair command cancellation

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

wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash

When an AER error occurs and the bus is hung, the register reads return 0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in an invalid memory access when accessing q->desc[] or q->entry[].

Unable to handle kernel paging request at virtual address ffffffc01099eac0 pc : mt76dmaaddbuf+0x124/0x188 [mt76] lr : mt76dmarxfill+0x11c/0x1d8 [mt76] sp : ffffffc016d9bbf0 x29: ffffffc016d9bc10 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffb7855e50b8 x25: ffffffb80d04f000 x24: 0000000000000000 x23: 0000000000000ec0 x22: ffffffb796803648 x21: ffffffb796801f80 x20: ffffffb7968035f8 x19: 0000000000000ec0 x18: 0000000000000000 x17: 000000004ec00000 x16: 000000000ec00000 x15: ffffffc01099eac0 x14: 000000004ec00000 x13: 00000000ffc5a000 x12: ffffffc016d9bc32 x11: 00000000ffffffff x10: 0000000000000002 x9 : 0000000000000000 x8 : 000000000000b4ac x7 : 0000000000000a20 x6 : ffffffb6c1806400 x5 : 0000000000000000 x4 : ffffffb80d04f000 x3 : 0000000000000000 x2 : 0000000000000001 x1 : 000000000ec04000 x0 : ffffffb7968035f8 Call trace: mt76dmaaddbuf+0x124/0x188 [mt76 (HASH:1029 4)] mt76dmarxreset+0xe8/0xfc [mt76 (HASH:1029 4)] mt7921wpdmareset+0x188/0x1b0 [mt7921e (HASH:ee48 5)] mt7921emacreset+0x128/0x418 [mt7921e (HASH:ee48 5)] mt7921macresetwork+0xac/0x1a8 [mt7921common (HASH:f721 6)] processonework+0x188/0x514 workerthread+0x12c/0x300 kthread+0x140/0x1fc retfromfork+0x10/0x30

Fix the invalid memory access by validating the DMA index read from the hardware before it is used as a queue index. An out-of-range value, such as the 0xFFFFFFFF returned while the bus is hung, is now clamped so it can no longer corrupt q->head or q->tail. In addition, check the bushung flag in mt7921macresetwork() before attempting the reset sequence, reject MCU messages while the bus is hung, and install no-op bus operations when an unrecoverable AER error is detected, preventing further invalid hardware accesses.

Due to hardware limitations - such as the lack of a connected hardware reset pin or the absence of host re-probe functionality - affected Wi-Fi devices may not fully recover to a normal operational state after certain errors, even with AER enabled.

HID: sony: fix UAF of ghlpoketimer / ghlurb at driver unbind

gpio: mvebu: free generic chips on unbind

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

nvme-apple: Destroy the admin queue on removal

The admin queue is allocated with blkmqallocqueue() but never destroyed. nvmefreectrl() only drops the last reference and blkmqexitqueue() and blksyncqueue() never run: the hctx is never moved to q->unusedhctxlist and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blkmqtimeoutwork().

This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before.

Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvmeuninitctrl().

With this the following WARN followed by a panic no longer happens:

WARNING: block/blk-mq.c:4390 at blkmqrelease+0x194/0x238, CPU#4: kworker/u34:4/119 CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: nvme-wq applenvmeremovedeadctrlwork pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : blkmqrelease+0x194/0x238 lr : blkmqrelease+0x58/0x238 sp : ffffc000833a3b50 x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200 x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805 x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60 x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000 x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8 x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001 x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698 Call trace: blkmqrelease+0x194/0x238 (P) blkputqueue+0x8c/0xf0 nvmefreectrl+0x4c/0x260 devicerelease+0x44/0x128 kobjectput+0xa0/0x120 putdevice+0x1c/0x40 nvmeuninitctrl+0x48/0x60 applenvmeremove+0x54/0xb0 platformremove+0x28/0x40 deviceremove+0x54/0x98 devicereleasedriverinternal+ devicereleasedriver+0x20/0x38 applenvmeremovedeadctrlwor processonework+0x1f4/0x770 workerthread+0x1b8/0x360 kthread+0x140/0x160 retfromfork+0x10/0x20 irq event stamp: 448 hardirqs last enabled at (447):inunlockirqrestore+0x74/0x80 hardirqs last disabled at (448): [<ffffc000811cf5c0>] el1brk64+0x20/0x60 softirqs last enabled at (0): [ess+0xb28/0x2698 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagA GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000000] user address Internal error: Oops: 0000000096000005 [#1] SMP CPU: 7 UID: 0 PID: 54 Comm: kwor 7.2.0-rc1-dirty #248PREEMPT Tainted: [W]=WARN Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: kblockd blkmqtimeou pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : percpureftrygetmany.cons lr : percpureftrygetmany.constprop.0+0xc0/0x168 sp : ffffc000829cbce0 x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0 x26: 0000000000000108 x25: 000009c05 x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48 x20: ffff8001deda4808 x19: ffff8000a x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000 x14: 0000000000000028 x13: 000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20 x8 : ---truncated---

Bluetooth: ISO: Fix data-race on isopi fields in hcigetroute calls

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

RDMA/mlx5: Fix UMR hang in LAG error state unload

During firmware reset in LAG mode, a race condition causes the driver to hang indefinitely while waiting for UMR completion during device unload. See [1].

In LAG mode the bond device is only registered on the master, so it never sees syserror events from the slave. During firmware reset this causes UMR waits to hang forever on unload as the slave is dead but the master hasn't entered error state yet, so UMR posts succeed but completions never arrive.

Fix this by adding a syserror notifier that gets registered before MLX5IBSTAGEIBREG and stays alive until after ibunregisterdevice(). This ensures error events reach the bond device throughout teardown.

[1] Call Trace: schedule+0x2bd/0x760 schedule+0x37/0xa0 schedulepreemptdisabled+0xa/0x10 mutexlock.isra.6+0x2b5/0x4a0 mlx5ibderegmr+0x606/0x870 [mlx5ib] ? xaerase+0x4a/0xa0 ? condresched+0x15/0x30 ? waitforcompletion+0x31/0x100 ibderegmruser+0x48/0xc0 [ibcore] ? rdmacgunchargehierarchy+0xa0/0x100 destroyhwidruobject+0x20/0x50 [ibuverbs] uverbsdestroyuobject+0x37/0x150 [ibuverbs] uverbscleanupufile+0xda/0x140 [ibuverbs] uverbsdestroyufilehw+0x3a/0xf0 [ibuverbs] ibuverbsremoveone+0xc3/0x140 [ibuverbs] removeclientcontext+0x8b/0xd0 [ibcore] disabledevice+0x8c/0x130 [ibcore] ibunregisterdevice+0x10d/0x180 [ibcore] ibunregisterdevice+0x21/0x30 [ibcore] mlx5ibremove+0x1e4/0x1f0 [mlx5ib] auxiliarybusremove+0x1e/0x30 devicereleasedriverinternal+0x103/0x1f0 busremovedevice+0xf7/0x170 devicedel+0x181/0x410 mlx5rescandriverslocked.part.10+0xa9/0x1d0 [mlx5core] mlx5disablelag+0x253/0x260 [mlx5core] mlx5lagdisablechange+0x89/0xc0 [mlx5core] mlx5eswitchdisable+0x67/0xa0 [mlx5core] mlx5unload+0x15/0xd0 [mlx5core] mlx5unloadone+0x71/0xc0 [mlx5core] mlx5syncresetreloadwork+0x83/0x100 [mlx5core] processonework+0x1a7/0x360 workerthread+0x30/0x390 ? createworker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthreadflushworkfn+0x10/0x10 retfromfork+0x22/0x40

Bluetooth: ISO: zero the sockaddr before returning it in getname

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

zram: fix out-of-bounds access in readblockstate()

readblockstate() calculates nrpages before taking devlock. If the device is reset and reinitialized with a smaller disksize before lock acquisition, nrpages still describes the old table. The subsequent loop can then call slotlock() past the end of the newly allocated table.

Read disksize after acquiring devlock and checking that the device is initialized. The read lock then keeps the table and its bound stable for the duration of the scan.