Bluetooth: virtiobt: validate rx pkttype header length

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

ASoC: SOF: Don't allow pointer operations on unconfigured streams

When reporting the pointer for a compressed stream we report the current I/O frame position by dividing the position by the number of channels multiplied by the number of container bytes. These values default to 0 and are only configured as part of setting the stream parameters so this allows a divide by zero to be configured. Validate that they are non zero, returning an error if not

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

spi: microchip-core-qspi: control built-in cs manually

The coreQSPI IP supports only a single chip select, which is automagically operated by the hardware - set low when the transmit buffer first gets written to and set high when the number of bytes written to the TOTALBYTES field of the FRAMES register have been sent on the bus. Additional devices must use GPIOs for their chip selects. It was reported to me that if there are two devices attached to this QSPI controller that the in-built chip select is set low while linux tries to access the device attached to the GPIO.

This went undetected as the boards that connected multiple devices to the SPI controller all exclusively used GPIOs for chip selects, not relying on the built-in chip select at all. It turns out that this was because the built-in chip select, when controlled automagically, is set low when active and high when inactive, thereby ruling out its use for active-high devices or devices that need to transmit with the chip select disabled.

Modify the driver so that it controls chip select directly, retaining the behaviour for memops of setting the chip select active for the entire duration of the transfer in the execop callback. For regular transfers, implement the setcs callback for the core to use.

As part of this, the existing setup callback, mchpcoreqspisetupop(), is removed. Modifying the CLKIDLE field is not safe to do during operation when there are multiple devices, so this code is removed entirely. Setting the MASTER and ENABLE fields is something that can be done once at probe, it doesn't need to be re-run for each device. Instead the new setup callback sets the built-in chip select to its inactive state for active-low devices, as the reset value of the chip select in software controlled mode is low.

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

KVM: x86: Ignore -EBUSY when checking nested events from vcpublock()

Ignore -EBUSY when checking nested events after exiting a blocking state while L2 is active, as exiting to userspace will generate a spurious userspace exit, usually with KVMEXITUNKNOWN, and likely lead to the VM's demise. Continuing with the wakeup isn't perfect either, as something has gone sideways if a vCPU is awakened in L2 with an injected event (or worse, a nested run pending), but continuing on gives the VM a decent chance of surviving without any major side effects.

As explained in the Fixes commits, it should be impossible for a vCPU to be put into a blocking state with an already-injected event (exception, IRQ, or NMI). Unfortunately, userspace can stuff MPSTATE and/or injected events, and thus put the vCPU into what should be an impossible state.

Don't bother trying to preserve the WARN, e.g. with an anti-syzkaller Kconfig, as WARNs can (hopefully) be added in paths where KVM would be violating x86 architecture, e.g. by WARNing if KVM attempts to inject an exception or interrupt while the vCPU isn't running.

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

Bluetooth: MGMT: validate mesh send advertising payload length

meshsend() currently bounds MGMTOPMESHSEND by total command length, but it never verifies that the bytes supplied for the flexible advdata[] array actually match the embedded advdatalen field. MGMTMESHSENDSIZE only covers the fixed header, so a truncated command can still pass the existing 20..50 byte range check and later drive the async mesh send path past the end of the queued command buffer.

Keep rejecting zero-length and oversized advertising payloads, but validate advdatalen explicitly and require the command length to exactly match the flexible array size before queueing the request.

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

pmdomain: imx8mp-blk-ctrl: Keep the NOCHDCP clock enabled

Keep the NOCHDCP clock always enabled to fix the potential hang caused by the NoC ADB400 port power down handshake.

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

arm64: Set nocfi on swsusparchresume()

A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusparchsuspendexit() is marked with SYMCODE() and does not have a CFI hash, but swsusparchresume() will attempt to verify the CFI hash when calling a copy of swsusparchsuspendexit().

Given that there's an existing requirement that the entrypoint to swsusparchsuspendexit() is the first byte of the .hibernateexit.text section, we cannot fix this by marking swsusparchsuspendexit() with SYMFUNC(). The simplest fix for now is to disable the CFI check in swsusparchresume().

Mark swsusparchresume() as nocfi to disable the CFI check.

[1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but activemm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusparchresume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusparchresume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusparchresume+0x2ac/0x344 [ 22.991934][ T1] hibernationrestore+0x158/0x18c [ 22.991934][ T1] loadimageandrestore+0xb0/0xec [ 22.991934][ T1] softwareresume+0xf4/0x19c [ 22.991934][ T1] softwareresumeinitcall+0x34/0x78 [ 22.991934][ T1] dooneinitcall+0xe8/0x370 [ 22.991934][ T1] doinitcalllevel+0xc8/0x19c [ 22.991934][ T1] doinitcalls+0x70/0xc0 [ 22.991934][ T1] dobasicsetup+0x1c/0x28 [ 22.991934][ T1] kernelinitfreeable+0xe0/0x148 [ 22.991934][ T1] kernelinit+0x20/0x1a8 [ 22.991934][ T1] retfromfork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)

[catalin.marinas@arm.com: commit log updated by Mark Rutland]

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

ASoC: tlv320adcx140: fix null pointer

The "sndsoccomponent" in "adcx140priv" was only used once but never set. It was only used for reaching "dev" which is already present in "adcx140priv".

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

LoongArch: BPF: Sign extend kfunc call arguments

The kfunc calls are native calls so they should follow LoongArch calling conventions. Sign extend its arguments properly to avoid kernel panic. This is done by adding a new emitabiext() helper. The emitabiext() helper performs extension in place meaning a value already store in the target register (Note: this is different from the existing signextend() helper and thus we can't reuse it).

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

drm/i915: Fix system suspend without fbdev being initialized

If fbdev is not initialized for some reason - in practice on platforms without display - suspending fbdev should be skipped during system suspend, fix this up. While at it add an assert that suspending fbdev only happens with the display present.

This fixes the following:

[ 91.227923] PM: suspend entry (s2idle) [ 91.254598] Filesystems sync: 0.025 seconds [ 91.270518] Freezing user space processes [ 91.272266] Freezing user space processes completed (elapsed 0.001 seconds) [ 91.272686] OOM killer disabled. [ 91.272872] Freezing remaining freezable tasks [ 91.274295] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 91.659622] BUG: kernel NULL pointer dereference, address: 00000000000001c8 [ 91.659981] #PF: supervisor write access in kernel mode [ 91.660252] #PF: errorcode(0x0002) - not-present page [ 91.660511] PGD 0 P4D 0 [ 91.660647] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 91.660875] CPU: 4 PID: 917 Comm: bash Not tainted 6.2.0-rc7+ #54 [ 91.661185] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20221117gitfff6d81270b5-9.fc37 unknown [ 91.661680] RIP: 0010:mutexlock+0x19/0x30 [ 91.661914] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 62 d3 ff ff 31 c0 65 48 8b 14 25 00 15 03 00 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b4 0f 1f 40 [ 91.662840] RSP: 0018:ffffa1e8011ffc08 EFLAGS: 00010246 [ 91.663087] RAX: 0000000000000000 RBX: 00000000000001c8 RCX: 0000000000000000 [ 91.663440] RDX: ffff8be455eb0000 RSI: 0000000000000001 RDI: 00000000000001c8 [ 91.663802] RBP: ffff8be459440000 R08: ffff8be459441f08 R09: ffffffff8e1432c0 [ 91.664167] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [ 91.664532] R13: 00000000000001c8 R14: 0000000000000000 R15: ffff8be442f4fb20 [ 91.664905] FS: 00007f28ffc16740(0000) GS:ffff8be4bb900000(0000) knlGS:0000000000000000 [ 91.665334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 91.665626] CR2: 00000000000001c8 CR3: 0000000114926006 CR4: 0000000000770ee0 [ 91.665988] PKRU: 55555554 [ 91.666131] Call Trace: [ 91.666265] <TASK> [ 91.666381] intelfbdevsetsuspend+0x97/0x1b0 [i915] [ 91.666738] i915drmsuspend+0xb9/0x100 [i915] [ 91.667029] pcipmsuspend+0x78/0x170 [ 91.667234] ? pfxpcipmsuspend+0x10/0x10 [ 91.667461] dpmruncallback+0x47/0x150 [ 91.667673] devicesuspend+0x10a/0x4e0 [ 91.667880] dpmsuspend+0x134/0x270 [ 91.668069] dpmsuspendstart+0x79/0x80 [ 91.668272] suspenddevicesandenter+0x11b/0x890 [ 91.668526] pmsuspend.cold+0x270/0x2fc [ 91.668737] statestore+0x46/0x90 [ 91.668916] kernfsfopwriteiter+0x11b/0x200 [ 91.669153] vfswrite+0x1e1/0x3a0 [ 91.669336] ksyswrite+0x53/0xd0 [ 91.669510] dosyscall64+0x58/0xc0 [ 91.669699] ? syscallexittousermodeprepare+0x18e/0x1c0 [ 91.669980] ? syscallexittousermodeprepare+0x18e/0x1c0 [ 91.670278] ? syscallexittousermode+0x17/0x40 [ 91.670524] ? dosyscall64+0x67/0xc0 [ 91.670717] ? irqexitrcu+0x3d/0x140 [ 91.670931] entrySYSCALL64afterhwframe+0x72/0xdc [ 91.671202] RIP: 0033:0x7f28ffd14284

v2: CC stable. (Jani)

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015 (cherry picked from commit 9542d708409a41449e99c9a464deb5e062c4bee2)

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

blk-mq: avoid double ->queuerq() because of early timeout

David Jeffery found one double ->queuerq() issue, so far it can be triggered in VM use case because of long vmexit latency or preempt latency of vCPU pthread or long page fault in vCPU pthread, then block IO req could be timed out before queuing the request to hardware but after calling blkmqstartrequest() during ->queuerq(), then timeout handler may handle it by requeue, then double ->queuerq() is caused, and kernel panic.

So far, it is driver's responsibility to cover the race between timeout and completion, so it seems supposed to be solved in driver in theory, given driver has enough knowledge.

But it is really one common problem, lots of driver could have similar issue, and could be hard to fix all affected drivers, even it isn't easy for driver to handle the race. So David suggests this patch by draining in-progress ->queuerq() for solving this issue.

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

tracing/hist: Fix out-of-bound write on 'actiondata.varrefidx'

When generate a synthetic event with many params and then create a trace action for it [1], kernel panic happened [2].

It is because that in traceactioncreate() 'data->nparams' is up to SYNTHFIELDSMAX (current value is 64), and array 'data->varrefidx' keeps indices into array 'histdata->varrefs' for each synthetic event param, but the length of 'data->varrefidx' is TRACINGMAPVARSMAX (current value is 16), so out-of-bound write happened when 'data->nparams' more than 16. In this case, 'data->matchdata.event' is overwritten and eventually cause the panic.

To solve the issue, adjust the length of 'data->varrefidx' to be SYNTHFIELDSMAX and add sanity checks to avoid out-of-bound write.

[1] # cd /sys/kernel/tracing/ # echo "mysynthevent int v1; int v2; int v3; int v4; int v5; int v6;\ int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\ int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\ int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\ int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\ int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\ int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\ int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\ int v63" >> syntheticevents # echo 'hist:keys=pid:ts0=commontimestamp.usecs if comm=="bash"' >> \ events/sched/schedwaking/trigger # echo "hist:keys=nextpid:onmatch(sched.schedwaking).mysynthevent(\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\ pid,pid,pid,pid,pid,pid,pid,pid,pid)" >> events/sched/schedswitch/trigger

[2] BUG: unable to handle page fault for address: ffff91c900000000 PGD 61001067 P4D 61001067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:strcmp+0xc/0x30 Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14 07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3 RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000 RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000 R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580 R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538 FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0 Call Trace: <TASK> findeventfile+0x55/0x90 actioncreate+0x76c/0x1060 eventhisttriggerparse+0x146d/0x2060 ? eventtriggerwrite+0x31/0xd0 triggerprocessregex+0xbb/0x110 eventtriggerwrite+0x6b/0xd0 vfswrite+0xc8/0x3e0 ? allocfd+0xc0/0x160 ? preemptcountadd+0x4d/0xa0 ? preemptcountadd+0x70/0xa0 ksyswrite+0x5f/0xe0 dosyscall64+0x3b/0x90 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7f1d1d0cf077 Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077 RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001 RBP: 00005639265aa7e0 R08: 000000000000000a R09: 0000000000000142 R ---truncated---

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

dm thin: Fix ABBA deadlock between shrinkslab and dmpoolabortmetadata

Following concurrent processes:

P1(drop cache) P2(kworker) dropcachessysctlhandler dropslab shrinkslab downread(&shrinkerrwsem) - LOCK A doshrinkslab supercachescan pruneicachesb disposelist evict ext4evictinode ext4clearinode ext4discardpreallocations ext4mbloadbuddygfp ext4mbinitcache ext4readblockbitmapnowait ext4readbhnowait submitbh dmsubmitbio doworker processdeferredbios commit metadataoperationfailed dmpoolabortmetadata downwrite(&pmd->rootlock) - LOCK B destroypersistentdataobjects dmblockmanagerdestroy dmbufioclientdestroy unregistershrinker downwrite(&shrinkerrwsem) thinmap | dmthinfindblock ↓ downread(&pmd->rootlock) --> ABBA deadlock

, which triggers hung task:

[ 76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds. [ 76.976019] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910 [ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2 [ 76.978534] Workqueue: dm-thin doworker [ 76.978552] Call Trace: [ 76.978564] schedule+0x6ba/0x10f0 [ 76.978582] schedule+0x9d/0x1e0 [ 76.978588] rwsemdownwriteslowpath+0x587/0xdf0 [ 76.978600] downwrite+0xec/0x110 [ 76.978607] unregistershrinker+0x2c/0xf0 [ 76.978616] dmbufioclientdestroy+0x116/0x3d0 [ 76.978625] dmblockmanagerdestroy+0x19/0x40 [ 76.978629] destroypersistentdataobjects+0x5e/0x70 [ 76.978636] dmpoolabortmetadata+0x8e/0x100 [ 76.978643] metadataoperationfailed+0x86/0x110 [ 76.978649] commit+0x6a/0x230 [ 76.978655] doworker+0xc6e/0xd90 [ 76.978702] processonework+0x269/0x630 [ 76.978714] workerthread+0x266/0x630 [ 76.978730] kthread+0x151/0x1b0 [ 76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds. [ 76.979756] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910 [ 76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459 [ 76.982128] Call Trace: [ 76.982139] schedule+0x6ba/0x10f0 [ 76.982155] schedule+0x9d/0x1e0 [ 76.982159] rwsemdownreadslowpath+0x4f4/0x910 [ 76.982173] downread+0x84/0x170 [ 76.982177] dmthinfindblock+0x4c/0xd0 [ 76.982183] thinmap+0x201/0x3d0 [ 76.982188] mapbio+0x5b/0x350 [ 76.982195] dmsubmitbio+0x2b6/0x930 [ 76.982202] submitbio+0x123/0x2d0 [ 76.982209] submitbionoacctnocheck+0x101/0x3e0 [ 76.982222] submitbionoacct+0x389/0x770 [ 76.982227] submitbio+0x50/0xc0 [ 76.982232] submitbhwbc+0x15e/0x230 [ 76.982238] submitbh+0x14/0x20 [ 76.982241] ext4readbhnowait+0xc5/0x130 [ 76.982247] ext4readblockbitmapnowait+0x340/0xc60 [ 76.982254] ext4mbinitcache+0x1ce/0xdc0 [ 76.982259] ext4mbloadbuddygfp+0x987/0xfa0 [ 76.982263] ext4discardpreallocations+0x45d/0x830 [ 76.982274] ext4clearinode+0x48/0xf0 [ 76.982280] ext4evictinode+0xcf/0xc70 [ 76.982285] evict+0x119/0x2b0 [ 76.982290] disposelist+0x43/0xa0 [ 76.982294] pruneicachesb+0x64/0x90 [ 76.982298] supercachescan+0x155/0x210 [ 76.982303] doshrinkslab+0x19e/0x4e0 [ 76.982310] shrinkslab+0x2bd/0x450 [ 76.982317] dropslab+0xcc/0x1a0 [ 76.982323] dropcachessysctlhandler+0xb7/0xe0 [ 76.982327] procsyscallhandler+0x1bc/0x300 [ 76.982331] procsyswrite+0x17/0x20 [ 76.982334] vfswrite+0x3d3/0x570 [ 76.982342] ksyswrite+0x73/0x160 [ 76.982347] x64syswrite+0x1e/0x30 [ 76.982352] dosyscall64+0x35/0x80 [ 76.982357] entrySYSCALL64afterhwframe+0x63/0xcd

Funct ---truncated---

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

blk-iolatency: Fix memory leak on adddisk() failures

When a gendisk is successfully initialized but adddisk() fails such as when a loop device has invalid number of minor device numbers specified, blkcginitdisk() is called during init and then blkcgexitdisk() during error handling. Unfortunately, iolatency gets initialized in the former but doesn't get cleaned up in the latter.

This is because, in non-error cases, the cleanup is performed by delgendisk() calling rqqosexit(), the assumption being that rqqos policies, iolatency being one of them, can only be activated once the disk is fully registered and visible. That assumption is true for wbt and iocost, but not so for iolatency as it gets initialized before adddisk() is called.

It is desirable to lazy-init rqqos policies because they are optional features and add to hot path overhead once initialized - each IO has to walk all the registered rqqos policies. So, we want to switch iolatency to lazy init too. However, that's a bigger change. As a fix for the immediate problem, let's just add an extra call to rqqosexit() in blkcgexitdisk(). This is safe because duplicate calls to rqqosexit() become noop's.

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

media: i2c: hi846: Fix memory leak in hi846parsedt()

If any of the checks related to the supported link frequencies fail, then the V4L2 fwnode resources don't get released before returning, which leads to a memleak. Fix this by properly freeing the V4L2 fwnode data in a designated label.

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

media: solo6x10: fix possible memory leak in solosysfsinit()

If deviceregister() returns error in solosysfsinit(), the name allocated by devsetname() need be freed. As comment of deviceregister() says, it should use putdevice() to give up the reference in the error path. So fix this by calling putdevice(), then the name can be freed in kobjectcleanup().

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

r6040: Fix kmemleak in probe and remove

There is a memory leaks reported by kmemleak:

unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff815bcd82>] kmalloctrace+0x22/0x60 [<ffffffff827e20ee>] phydevicecreate+0x4e/0x90 [<ffffffff827e6072>] getphydevice+0xd2/0x220 [<ffffffff827e7844>] mdiobusscan+0xa4/0x2e0 [<ffffffff827e8be2>] mdiobusregister+0x482/0x8b0 [<ffffffffa01f5d24>] r6040initone+0x714/0xd2c [r6040] ...

The problem occurs in probe process as follows: r6040initone: mdiobusregister mdiobusscan <- alloc and register phydevice, the reference count of phydevice is 3 r6040miiprobe phyconnect <- connect to the first phydevice, so the reference count of the first phydevice is 4, others are 3 registernetdev <- fault inject succeeded, goto error handling path

// error handling path erroutmdiounregister: mdiobusunregister(lp->miibus); erroutmdio: mdiobusfree(lp->miibus); <- the reference count of the first phydevice is 1, it is not released and other phydevices are released // similarly, the remove process also has the same problem

The root cause is traced to the phydevice is not disconnected when removes one r6040 device in r6040removeone() or on error handling path after r6040mii probed successfully. In r6040miiprobe(), a net ethernet device is connected to the first PHY device of miibus, in order to notify the connected driver when the link status changes, which is the default behavior of the PHY infrastructure to handle everything. Therefore the phydevice should be disconnected when removes one r6040 device or on error handling path.

Fix it by adding phydisconnect() when removes one r6040 device or on error handling path after r6040mii probed successfully.

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

vme: Fix error not catched in fakeinit()

In fakeinit(), rootdeviceregister() is possible to fail but it's ignored, which can cause unregistering vmeroot fail when exit.

general protection fault, probably for non-canonical address 0xdffffc000000008c KASAN: null-ptr-deref in range [0x0000000000000460-0x0000000000000467] RIP: 0010:rootdeviceunregister+0x26/0x60 Call Trace: <TASK> x64sysdeletemodule+0x34f/0x540 dosyscall64+0x38/0x90 entrySYSCALL64afterhwframe+0x63/0xcd

Return error when rootdeviceregister() fails.

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

firmware: raspberrypi: fix possible memory leak in rpifirmwareprobe()

In rpifirmwareprobe(), if mboxrequestchannel() fails, the 'fw' will not be freed through rpifirmwaredelete(), fix this leak by calling kfree() in the error path.

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

x86: fix clearuserrepgood() exception handling annotation

This code no longer exists in mainline, because it was removed in commit d2c95f9d6802 ("x86: don't use REPGOOD or ERMS for user memory clearing") upstream.

However, rather than backport the full range of x86 memory clearing and copying cleanups, fix the exception table annotation placement for the final 'rep movsb' in clearuserrepgood(): rather than pointing at the actual instruction that did the user space access, it pointed to the register move just before it.

That made sense from a code flow standpoint, but not from an actual usage standpoint: it means that if user access takes an exception, the exception handler won't actually find the instruction in the exception tables.

As a result, rather than fixing it up and returning -EFAULT, it would then turn it into a kernel oops report instead, something like:

BUG: unable to handle page fault for address: 0000000020081000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page ... RIP: 0010:clearuserrepgood+0x1c/0x30 arch/x86/lib/clearpage64.S:147 ... Call Trace: clearuser arch/x86/include/asm/uaccess64.h:103 [inline] clearuser arch/x86/include/asm/uaccess64.h:124 [inline] ioviterzero+0x709/0x1290 lib/ioviter.c:800 iomapdioholeiter fs/iomap/direct-io.c:389 [inline] iomapdioiter fs/iomap/direct-io.c:440 [inline] iomapdiorw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601 iomapdiorw+0x40/0xa0 fs/iomap/direct-io.c:689 ext4dioreaditer fs/ext4/file.c:94 [inline] ext4filereaditer+0x4be/0x690 fs/ext4/file.c:145 callreaditer include/linux/fs.h:2183 [inline] doiterreadvwritev+0x2e0/0x3b0 fs/readwrite.c:733 doiterread+0x2f2/0x750 fs/readwrite.c:796 vfsreadv+0xe5/0x150 fs/readwrite.c:916 dopreadv+0x1b6/0x270 fs/readwrite.c:1008 dosyspreadv2 fs/readwrite.c:1070 [inline] sesyspreadv2 fs/readwrite.c:1061 [inline] x64syspreadv2+0xef/0x150 fs/readwrite.c:1061 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x39/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

which then looks like a filesystem bug rather than the incorrect exception annotation that it is.

[ The alternative to this one-liner fix is to take the upstream series that cleans this all up:

68674f94ffc9 ("x86: don't use REPGOOD or ERMS for small memory copies") 20f3337d350c ("x86: don't use REPGOOD or ERMS for small memory clearing") adfcf4231b8c ("x86: don't use REPGOOD or ERMS for user memory copies") d2c95f9d6802 ("x86: don't use REPGOOD or ERMS for user memory clearing") 3639a535587d ("x86: move stac/clac from user copy routines into callers") 577e6a7fd50d ("x86: inline the 'rep movs' in user copies for the FSRM case") 8c9b6a88b7e2 ("x86: improve on the non-rep 'clearuser' function") 427fda2c8a49 ("x86: improve on the non-rep 'copyuser' function") e046fe5a36a9 ("x86: set FSRS automatically on AMD CPUs that have FSRM") e1f2750edc4a ("x86: remove 'zerorest' argument from copyusernocache()") 034ff37d3407 ("x86: rewrite 'copyusernocache' function")

with either the whole series or at a minimum the two marked commits being needed to fix this issue ]

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

drm/i915/gvt: fix vgpu debugfs clean in remove

Check carefully on root debugfs available when destroying vgpu, e.g in remove case drm minor's debugfs root might already be destroyed, which led to kernel oops like below.

Console: switching to colour dummy device 80x25 i915 0000:00:02.0: MDEV: Unregistering intelvgpumdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14 BUG: kernel NULL pointer dereference, address: 0000000000000150 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 3 PID: 1046 Comm: driverctl Not tainted 6.1.0-rc2+ #6 Hardware name: HP HP ProDesk 600 G3 MT/829D, BIOS P02 Ver. 02.44 09/13/2022 RIP: 0010:lockacquire+0x5e2/0x1f90 Code: 87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 ff <48> 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0 RSP: 0018:ffff9f770274f948 EFLAGS: 00010046 RAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8895d1173300 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000 FS: 00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000150 CR3: 000000010fd93005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> lockacquire+0xbf/0x2b0 ? simplerecursiveremoval+0xa5/0x2b0 ? lockrelease+0x13d/0x2d0 downwrite+0x2a/0xd0 ? simplerecursiveremoval+0xa5/0x2b0 simplerecursiveremoval+0xa5/0x2b0 ? startcreating.part.0+0x110/0x110 ? rawspinunlock+0x29/0x40 debugfsremove+0x40/0x60 intelgvtdebugfsremovevgpu+0x15/0x30 [kvmgt] intelgvtdestroyvgpu+0x60/0x100 [kvmgt] intelvgpureleasedev+0xe/0x20 [kvmgt] devicerelease+0x30/0x80 kobjectput+0x79/0x1b0 devicereleasedriverinternal+0x1b8/0x230 busremovedevice+0xec/0x160 devicedel+0x189/0x400 ? upwrite+0x9c/0x1b0 ? mdevdeviceremovecommon+0x60/0x60 [mdev] mdevdeviceremovecommon+0x22/0x60 [mdev] mdevdeviceremovecb+0x17/0x20 [mdev] deviceforeachchild+0x56/0x80 mdevunregisterparent+0x5a/0x81 [mdev] intelgvtcleandevice+0x2d/0xe0 [kvmgt] intelgvtdriverremove+0x2e/0xb0 [i915] i915driverremove+0xac/0x100 [i915] i915pciremove+0x1a/0x30 [i915] pcideviceremove+0x31/0xa0 devicereleasedriverinternal+0x1b8/0x230 unbindstore+0xd8/0x100 kernfsfopwriteiter+0x156/0x210 vfswrite+0x236/0x4a0 ksyswrite+0x61/0xd0 dosyscall64+0x55/0x80 ? findheldlock+0x2b/0x80 ? lockrelease+0x13d/0x2d0 ? upread+0x17/0x20 ? lockisheldtype+0xe3/0x140 ? asmexcpagefault+0x22/0x30 ? lockdephardirqson+0x7d/0x100 entrySYSCALL64afterhwframe+0x46/0xb0 RIP: 0033:0x7fc9b2c9e0c4 Code: 15 71 7d 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 80 3d 3d 05 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48 RSP: 002b:00007ffec29c81c8 EFLAGS: 00000202 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc9b2c9e0c4 RDX: 000000000000000d RSI: 0000559f8b5f48a0 RDI: 0000000000000001 RBP: 0000559f8b5f48a0 R08: 0000559f8b5f3540 R09: 00007fc9b2d76d30 R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000d R13: 00007fc9b2d77780 R14: 000000000000000d R15: 00007fc9b2d72a00 </TASK> Modules linked in: sunrpc intelraplmsr intelraplcommon intelpmccorepltdrv intelpmccore inteltcccooling x86pkgtempthermal intelpowerclamp coretemp kvmintel ee1004 igbvf rapl vfat fat intelcstate inteluncore pktcdvd i2ci801 pcspkr wmibmof i2csmbus acpipad vfiopci vfiopcicore vfiovirqfd zram fuse dm ---truncated---

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

dm thin: Use last transaction's pmd->root when commit failed

Recently we found a softlock up problem in dm thin pool btree lookup code due to corrupted metadata:

Kernel panic - not syncing: softlockup: hung tasks CPU: 7 PID: 2669225 Comm: kworker/u16:3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: dm-thin doworker [dmthinpool] Call Trace: <IRQ> dumpstack+0x9c/0xd3 panic+0x35d/0x6b9 watchdogtimerfn.cold+0x16/0x25 runhrtimer+0xa2/0x2d0 </IRQ> RIP: 0010:relinklru+0x102/0x220 [dmbufio] bufionew+0x11f/0x4f0 [dmbufio] newread+0xa3/0x1e0 [dmbufio] dmbmreadlock+0x33/0xd0 [dmpersistentdata] rostep+0x63/0x100 [dmpersistentdata] btreelookupraw.constprop.0+0x44/0x220 [dmpersistentdata] dmbtreelookup+0x16f/0x210 [dmpersistentdata] dmthinfindblock+0x12c/0x210 [dmthinpool] processbioreadonly+0xc5/0x400 [dmthinpool] processthindeferredbios+0x1a4/0x4a0 [dmthinpool] processonework+0x3c5/0x730

Following process may generate a broken btree mixed with fresh and stale btree nodes, which could get dm thin trapped in an infinite loop while looking up data block: Transaction 1: pmd->root = A, A->B->C // One path in btree pmd->root = X, X->Y->Z // Copy-up Transaction 2: X,Z is updated on disk, Y write failed. // Commit failed, dm thin becomes read-only. processbioreadonly dmthinfindblock findblock dmbtreelookup(pmd->root) The pmd->root points to a broken btree, Y may contain stale node pointing to any block, for example X, which gets dm thin trapped into a dead loop while looking up Z.

Fix this by setting pmd->root in openmetadata(), so that dm thin will use the last transaction's pmd->root if commit failed.

Fetch a reproducer in [Link].

Linke: https://bugzilla.kernel.org/showbug.cgi?id=216790

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

wifi: mac80211: mlme: fix null-ptr deref on failed assoc

If association to an AP without a link 0 fails, then we crash in tracing because it assumes that either apmldaddr or link 0 BSS is valid, since we clear sdata->vif.validlinks and then don't add the apmldaddr to the struct.

Since we clear also sdata->vif.cfg.apaddr, keep a local copy of it and assign it earlier, before clearing validlinks, to fix this.

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

scsi: mpt3sas: Fix possible resource leaks in mpt3sastransportportadd()

In mpt3sastransportportadd(), if sasrphyadd() returns error, sasrphyfree() needs be called to free the resource allocated in sasenddevicealloc(). Otherwise a kernel crash will happen:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : devicedel+0x54/0x3d0 lr : devicedel+0x37c/0x3d0 Call trace: devicedel+0x54/0x3d0 attributecontainerclassdevicedel+0x28/0x38 transportremoveclassdev+0x6c/0x80 attributecontainerdevicetrigger+0x108/0x110 transportremovedevice+0x28/0x38 sasrphyremove+0x50/0x78 [scsitransportsas] sasportdelete+0x30/0x148 [scsitransportsas] dosasphydelete+0x78/0x80 [scsitransportsas] deviceforeachchild+0x68/0xb0 sasremovechildren+0x30/0x50 [scsitransportsas] sasrphyremove+0x38/0x78 [scsitransportsas] sasportdelete+0x30/0x148 [scsitransportsas] dosasphydelete+0x78/0x80 [scsitransportsas] deviceforeachchild+0x68/0xb0 sasremovechildren+0x30/0x50 [scsitransportsas] sasremovehost+0x20/0x38 [scsitransportsas] scsihremove+0xd8/0x420 [mpt3sas]

Because transportadddevice() is not called when sasrphyadd() fails, the device is not added. When sasrphyremove() is subsequently called to remove the device in the remove() path, a NULL pointer dereference happens.

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

testfirmware: fix memory leak in testfirmwareinit()

When miscregister() failed in testfirmwareinit(), the memory pointed by testfwconfig->name is not released. The memory leak information is as follows: unreferenced object 0xffff88810a34cb00 (size 32): comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s) hex dump (first 32 bytes): 74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69 test-firmware.bi 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n............... backtrace: [<ffffffff81b21fcb>] kmallocnodetrackcaller+0x4b/0xc0 [<ffffffff81affb96>] kstrndup+0x46/0xc0 [<ffffffffa0403a49>] testfirmwareconfiginit+0x29/0x380 [testfirmware] [<ffffffffa040f068>] 0xffffffffa040f068 [<ffffffff81002c41>] dooneinitcall+0x141/0x780 [<ffffffff816a72c3>] doinitmodule+0x1c3/0x630 [<ffffffff816adb9e>] loadmodule+0x623e/0x76a0 [<ffffffff816af471>] dosysfinitmodule+0x181/0x240 [<ffffffff89978f99>] dosyscall64+0x39/0xb0 [<ffffffff89a0008b>] entrySYSCALL64afterhwframe+0x63/0xcd

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

drm/amdgpu: Fix size validation for non-exclusive domains (v4)

Fix amdgpubovalidatesize() to check whether the TTM domain manager for the requested memory exists, else we get a kernel oops when dereferencing "man".

v2: Make the patch standalone, i.e. not dependent on local patches. v3: Preserve old behaviour and just check that the manager pointer is not NULL. v4: Complain if GTT domain requested and it is uninitialized--most likely a bug.

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

iommu/fslpamu: Fix resource leak in fslpamuprobe()

The fslpamuprobe() returns directly when createcsd() failed, leaving irq and memories unreleased. Fix by jumping to error if createcsd() returns error.

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

iommu/mediatek: Check return value after calling platformgetresource()

platformgetresource() may return NULL pointer, we need check its return value to avoid null-ptr-deref in resourcesize().

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

clk: rockchip: Fix memory leak in rockchipclkregisterpll()

If clkregister() fails, @pll->ratetable may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it.

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

platform/x86: mxm-wmi: fix memleak in mxmwmicallmxds|mx

The ACPI buffer memory (out.pointer) returned by wmievaluatemethod() is not freed after the call, so it leads to memory leak.

The method results in ACPI buffer is not used, so just pass NULL to wmievaluatemethod() which fixes the memory leak.