In the Linux kernel, the following vulnerability has been resolved:
vt: prevent kernel-infoleak in confontget()
font.data may not initialize all memory spaces depending on the implementation of vc->vcsw->confontget. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftpayload: sanitize offset and length before calling skbchecksum()
If access to offset + length is larger than the skbuff length, then skbchecksum() triggers BUGON().
skbchecksum() internally subtracts the length parameter while iterating over skbuff, BUGON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: setup queue ->tagset before initializing hctx
Commit 7b815817aa58 ("blk-mq: add helper for checking if one CPU is mapped to specified hctx") needs to check queue mapping via tag set in hctx's cpuhp handler.
However, q->tagset may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered.
Fix the issue by setup queue tagset before initializing hctx.
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/tests/sysfs-kunit.h: fix memory leak in damonsysfstestaddtargets()
The sysfstarget->regions allocated in damonsysfsregionsalloc() is not freed in damonsysfstestaddtargets(), which cause the following memory leak, free it to fix it.
unreferenced object 0xffffff80c2a8db80 (size 96): comm "kunittrycatch", pid 187, jiffies 4294894363 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<0000000001e3714d>] kmemleakalloc+0x34/0x40 [<000000008e6835c1>] kmalloccachenoprof+0x26c/0x2f4 [<000000001286d9f8>] damonsysfstestaddtargets+0x1cc/0x738 [<0000000032ef8f77>] kunittryruncase+0x13c/0x3ac [<00000000f3edea23>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] retfromfork+0x10/0x20
In the Linux kernel, the following vulnerability has been resolved:
ublk: don't allow user copy for unprivileged device
UBLKFUSERCOPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted.
So don't allow user copy for unprivileged device.
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: apple: check devmkasprintf() returned value
devmkasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value.
Found by code review.
In the Linux kernel, the following vulnerability has been resolved:
iouring/sqpoll: ensure task state is TASKRUNNING when running taskwork
When the sqpoll is exiting and cancels pending work items, it may need to run taskwork. If this happens from within iouringcancelgeneric(), then it may be under waiting for the iouringtask waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASKINTERRUPTIBLE state.
Ensure that the task state is set appropriately for that, just like what is done for the other cases in ioruntaskwork().
do not call blocking ops when !TASKRUNNING; state=1 set at [<0000000029387fd2>] preparetowait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 mightsleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : mightsleep+0xf4/0x140 lr : mightsleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: mightsleep+0xf4/0x140 mutexlock+0x84/0x124 iohandletwlist+0xf4/0x260 tctxtaskworkrun+0x94/0x340 ioruntaskwork+0x1ec/0x3c0 iouringcancelgeneric+0x364/0x524 iosqthread+0x820/0x124c retfromfork+0x10/0x20
In the Linux kernel, the following vulnerability has been resolved:
x86/bugs: Use code segment selector for VERW operand
Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call:
general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restoreallswitchstack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: showregs+0x70/0x78 dieaddr+0x29/0x70 excgeneralprotection+0x13c/0x348 excbounds+0x98/0x98 handleexception+0x14d/0x14d excbounds+0x98/0x98 restoreallswitchstack+0xbe/0xcf excbounds+0x98/0x98 restoreallswitchstack+0xbe/0xcf
This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction:
#GP(0) - If a memory operand effective address is outside the CS, DS, ES, FS, or GS segment limit.
CLEARCPUBUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds.
[ mingo: Fixed the SOB chain. ]
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: stm32: check devmkasprintf() returned value
devmkasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value.
Found by code review.
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Don't crash in stacktop() for tasks without vDSO
Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stacktop(), it will derefence the NULL vdso pointer and crash.
This can for example happen when using kunit:
[<9000000000203874>] stacktop+0x58/0xa8 [<90000000002956cc>] archpickmmaplayout+0x164/0x220 [<90000000003c284c>] kunitvmmmapinit+0x108/0x12c [<90000000003c1fbc>] kunitaddresource+0x38/0x8c [<90000000003c2704>] kunitvmmmap+0x88/0xc8 [<9000000000410b14>] usercopytestinit+0xbc/0x25c [<90000000003c1db4>] kunittryruncase+0x5c/0x184 [<90000000003c3d54>] kunitgenericrunthreadfnadapter+0x24/0x48 [<900000000022e4bc>] kthread+0xc8/0xd4 [<9000000000200ce8>] retfromkernelthread+0xc/0xa4
bpf: Use rawspinlockt in ringbuf
In the Linux kernel, the following vulnerability has been resolved:
platform/x86/intel/pmc: Fix pmccoreiounmap to call iounmap for valid addresses
Commit 50c6dbdfd16e ("x86/ioremap: Improve iounmap() address range checks") introduces a WARN when adrress ranges of iounmap are invalid. On Thinkpad P1 Gen 7 (Meteor Lake-P) this caused the following warning to appear:
WARNING: CPU: 7 PID: 713 at arch/x86/mm/ioremap.c:461 iounmap+0x58/0x1f0 Modules linked in: rfkill(+) sndtimer(+) fjes(+) snd soundcore intelpmccore(+) int3403thermal(+) int340xthermalzone intelvsec pmttelemetry acpipad pmtclass acpitad int3400thermal acpithermalrel joydev loop nfnetlink zram xe drmsuballochelper nouveau i915 mxmwmi drmttmhelper gpusched drmgpuvm drmexec drmbuddy i2calgobit crct10difpclmul crc32pclmul ttm crc32cintel polyvalclmulni rtsxpcisdmmc ucsiacpi polyvalgeneric mmccore hidmultitouch drmdisplayhelper ghashclmulniintel typecucsi nvme sha512ssse3 video sha256ssse3 nvmecore intelvpu sha1ssse3 rtsxpci cec typec nvmeauth i2chidacpi i2chid wmi pinctrlmeteorlake serioraw ip6tables iptables fuse CPU: 7 UID: 0 PID: 713 Comm: (udev-worker) Not tainted 6.12.0-rc2iounmap+ #42 Hardware name: LENOVO 21KWCTO1WW/21KWCTO1WW, BIOS N48ET19W (1.06 ) 07/18/2024 RIP: 0010:iounmap+0x58/0x1f0 Code: 85 6a 01 00 00 48 8b 05 e6 e2 28 04 48 39 c5 72 19 eb 26 cc cc cc 48 ba 00 00 00 00 00 00 32 00 48 8d 44 02 ff 48 39 c5 72 23 <0f> 0b 48 83 c4 08 5b 5d 41 5c c3 cc cc cc cc 48 ba 00 00 00 00 00 RSP: 0018:ffff888131eff038 EFLAGS: 00010207 RAX: ffffc90000000000 RBX: 0000000000000000 RCX: ffff888e33b80000 RDX: dffffc0000000000 RSI: ffff888e33bc29c0 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8881598a8000 R09: ffff888e2ccedc10 R10: 0000000000000003 R11: ffffffffb3367634 R12: 00000000fe000000 R13: ffff888101d0da28 R14: ffffffffc2e437e0 R15: ffff888110b03b28 FS: 00007f3c1d4b3980(0000) GS:ffff888e33b80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005651cfc93578 CR3: 0000000124e4c002 CR4: 0000000000f70ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn.cold+0xb6/0x176 ? iounmap+0x58/0x1f0 ? reportbug+0x1f4/0x2b0 ? handlebug+0x58/0x90 ? excinvalidop+0x17/0x40 ? asmexcinvalidop+0x1a/0x20 ? iounmap+0x58/0x1f0 pmccoressramgetpmc+0x477/0x6c0 [intelpmccore] ? pfxpmccoressramgetpmc+0x10/0x10 [intelpmccore] ? pfxdopcienabledevice+0x10/0x10 ? pciwaitforpending+0x60/0x110 ? pcienabledeviceflags+0x1e3/0x2e0 ? pfxmtlcoreinit+0x10/0x10 [intelpmccore] pmccoressraminit+0x7f/0x110 [intelpmccore] mtlcoreinit+0xda/0x130 [intelpmccore] ? mutexinit+0xb9/0x130 pmccoreprobe+0x27e/0x10b0 [intelpmccore] ? rawspinlockirqsave+0x96/0xf0 ? pfxpmccoreprobe+0x10/0x10 [intelpmccore] ? pfxmutexunlock+0x10/0x10 ? pfxmutexlock+0x10/0x10 ? devicepmcheckcallbacks+0x82/0x370 ? acpidevpmattach+0x234/0x2b0 platformprobe+0x9f/0x150 reallyprobe+0x1e0/0x8a0 driverprobedevice+0x18c/0x370 ? pfxdriverattach+0x10/0x10 driverprobedevice+0x4a/0x120 driverattach+0x190/0x4a0 ? pfxdriverattach+0x10/0x10 busforeachdev+0x103/0x180 ? pfxbusforeachdev+0x10/0x10 ? klistaddtail+0x136/0x270 busadddriver+0x2fc/0x540 driverregister+0x1a5/0x360 ? pfxpmccoredriverinit+0x10/0x10 [intelpmccore] dooneinitcall+0xa4/0x380 ? pfxdooneinitcall+0x10/0x10 ? kasanunpoison+0x44/0x70 doinitmodule+0x296/0x800 loadmodule+0x5090/0x6ce0 ? pfxloadmodule+0x10/0x10 ? imapostreadfile+0x193/0x200 ? pfximapostreadfile+0x10/0x10 ? rwverifyarea+0x152/0x4c0 ? kernelreadfile+0x257/0x750 ? pfxkernelreadfile+0x10/0x10 ? pfxfilemapgetreadbatch+0x10/0x10 ? initmodulefromfile+0xd1/0x130 initmodulefromfile+0xd1/0x130 ? pfxinitmodulefromfile+0x10/0 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC
data->asserted will be NULL on JH7110 SoC since commit 82327b127d41 ("reset: starfive: Add StarFive JH7110 reset driver") was added. Add the judgment condition to avoid errors when calling resetcontrolstatus on JH7110 SoC.
drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: fix null ptr dereference in raid10size()
In raid10run() if raid10setqueuelimits() succeed, the return value is set to zero, and if following procedures failed raid10run() will return zero while mddev->private is still NULL, causing null ptr dereference in raid10size().
Fix the problem by only overwrite the return value if raid10setqueuelimits() failed.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Handle kstrdup failures for passwords
In smb3reconfigure(), after duplicating ctx->password and ctx->password2 with kstrdup(), we need to check for allocation failures.
If ses->password allocation fails, return -ENOMEM. If ses->password2 allocation fails, free ses->password, set it to NULL, and return -ENOMEM.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: sdm845: add missing soundwire runtime stream alloc
During the migration of Soundwire runtime stream allocation from the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845 soundcard was forgotten.
At this point any playback attempt or audio daemon startup, for instance on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer NULL dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: ... CPU: 5 UID: 0 PID: 1198 Comm: aplay Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty #18 Hardware name: Thundercomm Dragonboard 845c (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sdwstreamaddslave+0x44/0x380 [soundwirebus] lr : sdwstreamaddslave+0x44/0x380 [soundwirebus] sp : ffff80008a2035c0 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8 Call trace: sdwstreamaddslave+0x44/0x380 [soundwirebus] wsa881xhwparams+0x68/0x80 [sndsocwsa881x] sndsocdaihwparams+0x3c/0xa4 socpcmhwparams+0x230/0x660 dpcmbedaihwparams+0x1d0/0x3f8 dpcmfedaihwparams+0x98/0x268 sndpcmhwparams+0x124/0x460 sndpcmcommonioctl+0x998/0x16e8 sndpcmioctl+0x34/0x58 arm64sysioctl+0xac/0xf8 invokesyscall+0x48/0x104 el0svccommon.constprop.0+0x40/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0xe0 el0t64synchandler+0x120/0x12c el0t64sync+0x190/0x194 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22) ---[ end trace 0000000000000000 ]---
0000000000006108 <sdwstreamaddslave>: 6108: d503233f paciasp 610c: a9b97bfd stp x29, x30, [sp, #-112]! 6110: 910003fd mov x29, sp 6114: a90153f3 stp x19, x20, [sp, #16] 6118: a9025bf5 stp x21, x22, [sp, #32] 611c: aa0103f6 mov x22, x1 6120: 2a0303f5 mov w21, w3 6124: a90363f7 stp x23, x24, [sp, #48] 6128: aa0003f8 mov x24, x0 612c: aa0203f7 mov x23, x2 6130: a9046bf9 stp x25, x26, [sp, #64] 6134: aa0403f9 mov x25, x4 <-- x4 copied to x25 6138: a90573fb stp x27, x28, [sp, #80] 613c: aa0403fb mov x27, x4 6140: f9418400 ldr x0, [x0, #776] 6144: 9100e000 add x0, x0, #0x38 6148: 94000000 bl 0 <mutexlock> 614c: f8420f22 ldr x2, [x25, #32]! <-- offset 0x44 ^^^ This is 0x6108 + offset 0x44 from the beginning of sdwstreamaddslave() where data abort happens. wsa881xhwparams() is called with stream = NULL and passes it further in register x4 (5th argu ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Unregister notifier on eswitch init failure
It otherwise remains registered and a subsequent attempt at eswitch enabling might trigger warnings of the sort:
[ 682.589148] ------------[ cut here ]------------ [ 682.590204] notifier callback eswitchvportevent [mlx5core] already registered [ 682.590256] WARNING: CPU: 13 PID: 2660 at kernel/notifier.c:31 notifierchainregister+0x3e/0x90 [...snipped] [ 682.610052] Call Trace: [ 682.610369] <TASK> [ 682.610663] ? warn+0x7c/0x110 [ 682.611050] ? notifierchainregister+0x3e/0x90 [ 682.611556] ? reportbug+0x148/0x170 [ 682.611977] ? handlebug+0x36/0x70 [ 682.612384] ? excinvalidop+0x13/0x60 [ 682.612817] ? asmexcinvalidop+0x16/0x20 [ 682.613284] ? notifierchainregister+0x3e/0x90 [ 682.613789] atomicnotifierchainregister+0x25/0x40 [ 682.614322] mlx5eswitchenablelocked+0x1d4/0x3b0 [mlx5core] [ 682.614965] mlx5eswitchenable+0xc9/0x100 [mlx5core] [ 682.615551] mlx5deviceenablesriov+0x25/0x340 [mlx5core] [ 682.616170] mlx5coresriovconfigure+0x50/0x170 [mlx5core] [ 682.616789] sriovnumvfsstore+0xb0/0x1b0 [ 682.617248] kernfsfopwriteiter+0x117/0x1a0 [ 682.617734] vfswrite+0x231/0x3f0 [ 682.618138] ksyswrite+0x63/0xe0 [ 682.618536] dosyscall64+0x4c/0x100 [ 682.618958] entrySYSCALL64afterhwframe+0x4b/0x53
In the Linux kernel, the following vulnerability has been resolved:
USB: gadget: dummy-hcd: Fix "task hung" problem
The syzbot fuzzer has been encountering "task hung" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timerpending() and hrtimeractive() APIs.
The changeover blindly replaced the first by the second. However, timerpending() returns True when the timer is queued but not when its callback is running, whereas hrtimeractive() returns True when the hrtimer is queued or its callback is running. This difference occasionally caused dummyurbenqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usbkillurb() to hang, and things got worse from there.
Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new "timerpending" flag and setting or clearing it at the appropriate times.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc
Commit 15c7fab0e047 ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards") moved the allocation of Soundwire stream runtime from the Qualcomm Soundwire driver to each individual machine sound card driver, except that it forgot to update SC7280 card.
Just like for other Qualcomm sound cards using Soundwire, the card driver should allocate and release the runtime. Otherwise sound playback will result in a NULL pointer dereference or other effect of uninitialized memory accesses (which was confirmed on SDM845 having similar issue).
In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix one more kernel-infoleak in algo dumping
During fuzz testing, the following issue was discovered:
BUG: KMSAN: kernel-infoleak in copytoiter+0x598/0x2a30 copytoiter+0x598/0x2a30 skbdatagramiter+0x168/0x1060 skbcopydatagramiter+0x5b/0x220 netlinkrecvmsg+0x362/0x1700 sockrecvmsg+0x2dc/0x390 sysrecvfrom+0x381/0x6d0 x64sysrecvfrom+0x130/0x200 x64syscall+0x32c8/0x3cc0 dosyscall64+0xd8/0x1c0 entrySYSCALL64afterhwframe+0x79/0x81
Uninit was stored to memory at: copytouserstateextra+0xcc1/0x1e00 dumponestate+0x28c/0x5f0 xfrmstatewalk+0x548/0x11e0 xfrmdumpsa+0x1e0/0x840 netlinkdump+0x943/0x1c40 netlinkdumpstart+0x746/0xdb0 xfrmuserrcvmsg+0x429/0xc00 netlinkrcvskb+0x613/0x780 xfrmnetlinkrcv+0x77/0xc0 netlinkunicast+0xe90/0x1280 netlinksendmsg+0x126d/0x1490 socksendmsg+0x332/0x3d0 syssendmsg+0x863/0xc30 syssendmsg+0x285/0x3e0 x64syssendmsg+0x2d6/0x560 x64syscall+0x1316/0x3cc0 dosyscall64+0xd8/0x1c0 entrySYSCALL64afterhwframe+0x79/0x81
Uninit was created at: kmalloc+0x571/0xd30 attachauth+0x106/0x3e0 xfrmaddsa+0x2aa0/0x4230 xfrmuserrcvmsg+0x832/0xc00 netlinkrcvskb+0x613/0x780 xfrmnetlinkrcv+0x77/0xc0 netlinkunicast+0xe90/0x1280 netlinksendmsg+0x126d/0x1490 socksendmsg+0x332/0x3d0 syssendmsg+0x863/0xc30 syssendmsg+0x285/0x3e0 x64syssendmsg+0x2d6/0x560 x64syscall+0x1316/0x3cc0 dosyscall64+0xd8/0x1c0 entrySYSCALL64afterhwframe+0x79/0x81
Bytes 328-379 of 732 are uninitialized Memory access of size 732 starts at ffff88800e18e000 Data copied to user address 00007ff30f48aff0
CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Fixes copying of xfrm algorithms where some random data of the structure fields can end up in userspace. Padding in structures may be filled with random (possibly sensitve) data and should never be given directly to user-space.
A similar issue was resolved in the commit 8222d5910dae ("xfrm: Zero padding when dumping algos and encap")
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
In the Linux kernel, the following vulnerability has been resolved:
x86: fix user address masking non-canonical speculation issue
It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result:
<a href="https://access.redhat.com/security/cve/CVE-2020-12965">CVE-2020-12965</a> “Transient Execution of Non-Canonical Accesses“
Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window.
But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open.
Note that this affects not just the new address masking, but also the regular validuseraddress() check used by accessok(), and the asm version of the sign bit check in the getuser() helpers.
It does not affect putuser() or clearuser() variants, since there's no speculative result to be used in a gadget for those operations.
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Enable IRQ if doale() triggered in irq-enabled context
Unaligned access exception can be triggered in irq-enabled context such as user mode, in this case doale() may call getuser() which may cause sleep. Then we will get:
BUG: sleeping function called from invalid context at arch/loongarch/kernel/access-helper.h:7 inatomic(): 0, irqsdisabled(): 1, nonblock: 0, pid: 129, name: modprobe preemptcount: 0, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 129 Comm: modprobe Tainted: G W 6.12.0-rc1+ #1723 Tainted: [W]=WARN Stack : 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000 9000000105e0bc70 9000000105e0bc78 0000000000000000 0000000000000000 9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890 ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500 000000000000020c 000000000000000a 0000000000000000 0000000000000003 00000000000023f0 00000000000e1401 00000000072f8000 0000007ffbb0e260 0000000000000000 0000000000000000 9000000005437650 90000000055d5000 0000000000000000 0000000000000003 0000007ffbb0e1f0 0000000000000000 0000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec 00000000000000b0 0000000000000007 0000000000000003 0000000000071c1d ... Call Trace: [<9000000003803964>] showstack+0x64/0x1a0 [<9000000004c57464>] dumpstacklvl+0x74/0xb0 [<9000000003861ab4>] mightresched+0x154/0x1a0 [<900000000380c96c>] emulateloadstoreinsn+0x6c/0xf60 [<9000000004c58118>] doale+0x78/0x180 [<9000000003801bc8>] handleale+0x128/0x1e0
So enable IRQ if unaligned access exception is triggered in irq-enabled context to fix it.
In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Set SDEVOFFLINE when UFS is shut down
There is a history of deadlock if reboot is performed at the beginning of booting. SDEVQUIESCE was set for all LU's scsidevices by UFS shutdown, and at that time the audio driver was waiting on blkmqsubmitbio() holding a mutexlock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutexunlock of blkmqsubmitbio(). To solve this, set SDEVOFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error.
[ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 init [deviceshutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] switchto+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedulepreemptdisabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] mutexlock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] mutexlockslowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutexlock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] deviceshutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernelrestart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] arm64sysreboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invokesyscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0svccommon+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] doel0svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t64synchandler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t64sync+0x1a0/0x1a4
[ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 kworker/6:0 [bioqueueenter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] switchto+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] bioqueueenter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blkmqsubmitbio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] submitbio+0xb8/0x19c
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix kernel bug due to missing clearing of buffer delay flag
Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUGON check for the buffer delay flag in submitbhwbc() may fail, causing a kernel bug.
This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this.
This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: qcom: Fix NULL Dereference in asocqcomlpasscpuplatformprobe()
A devmkzalloc() in asocqcomlpasscpuplatformprobe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: reject ro->rw reconfiguration if there are hard ro requirements
[BUG] Syzbot reports the following crash:
BTRFS info (device loop0 state MCS): disabling free space tree BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREESPACETREE (0x1) BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREESPACETREEVALID (0x2) Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:backupsuperroots fs/btrfs/disk-io.c:1691 [inline] RIP: 0010:writeallsupers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041 Call Trace: <TASK> btrfscommittransaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530 btrfsdeletefreespacetree+0x383/0x730 fs/btrfs/free-space-tree.c:1312 btrfsstartprerwmount+0xf28/0x1300 fs/btrfs/disk-io.c:3012 btrfsremountrw fs/btrfs/super.c:1309 [inline] btrfsreconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534 btrfsreconfigureformount fs/btrfs/super.c:2020 [inline] btrfsgettreesubvol fs/btrfs/super.c:2079 [inline] btrfsgettree+0x918/0x1920 fs/btrfs/super.c:2115 vfsgettree+0x90/0x2b0 fs/super.c:1800 donewmount+0x2be/0xb40 fs/namespace.c:3472 domount fs/namespace.c:3812 [inline] dosysmount fs/namespace.c:4020 [inline] sesysmount+0x2d6/0x3c0 fs/namespace.c:3997 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
[CAUSE] To support mounting different subvolume with different RO/RW flags for the new mount APIs, btrfs introduced two workaround to support this feature:
- Skip mount option/feature checks if we are mounting a different subvolume
- Reconfigure the fs to RW if the initial mount is RO
Combining these two, we can have the following sequence:
- Mount the fs ro,rescue=all,clearcache,spacecache=v1 rescue=all will mark the fs as hard read-only, so no v2 cache clearing will happen.
- Mount a subvolume rw of the same fs. We go into btrfsgettreesubvol(), but fcmount() returns EBUSY because our new fc is RW, different from the original fs.
Now we enter btrfsreconfigureformount(), which switches the RO flag first so that we can grab the existing fsinfo. Then we reconfigure the fs to RW.
- During reconfiguration, option/features check is skipped This means we will restart the v2 cache clearing, and convert back to v1 cache. This will trigger fs writes, and since the original fs has "rescue=all" option, it skips the csum tree read.
And eventually causing NULL pointer dereference in super block writeback.
[FIX] For reconfiguration caused by different subvolume RO/RW flags, ensure we always run btrfscheckoptions() to ensure we have proper hard RO requirements met.
In fact the function btrfscheckoptions() doesn't really do many complex checks, but hard RO requirement and some feature dependency checks, thus there is no special reason not to do the check for mount reconfiguration.
In the Linux kernel, the following vulnerability has been resolved:
PCI: Hold rescan lock while adding devices during host probe
Since adding the PCI power control code, we may end up with a race between the pwrctl platform device rescanning the bus and host controller probe functions. The latter need to take the rescan lock when adding devices or we may end up in an undefined state having two incompletely added devices and hit the following crash when trying to remove the device over sysfs:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Call trace: pistrlen+0x14/0x150 kernfsfindns+0x80/0x13c kernfsremovebynamens+0x54/0xf0 sysfsremovebinfile+0x24/0x34 pciremoveresourcefiles+0x3c/0x84 pciremovesysfsdevfiles+0x28/0x38 pcistopbusdevice+0x8c/0xd8 pcistopbusdevice+0x40/0xd8 pcistopandremovebusdevicelocked+0x28/0x48 removestore+0x70/0xb0 devattrstore+0x20/0x38 sysfskfwrite+0x58/0x78 kernfsfopwriteiter+0xe8/0x184 vfswrite+0x2dc/0x308 ksyswrite+0x7c/0xec
In the Linux kernel, the following vulnerability has been resolved:
xfrm: validate new SA's prefixlen using SA family when sel.family is unset
This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.")
syzbot created an SA with usersa.sel.family = AFUNSPEC usersa.sel.prefixlens = 128 usersa.family = AFINET
Because of the AFUNSPEC selector, verifynewsainfo doesn't put limits on prefixlen{s,d}. But then copyfromuserstate sets x->sel.family to usersa.family (AFINET). Do the same conversion in verifynewsainfo before validating prefixlen{s,d}, since that's how prefixlen is going to be used later on.
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: fix unbalanced rpm put() with fencefini()
Currently we can call fencefini() twice if something goes wrong when sending the GuC CT for the tlb request, since we signal the fence and return an error, leading to the caller also calling fini() on the error path in the case of stack version of the flow, which leads to an extra rpm put() which might later cause device to enter suspend when it shouldn't. It looks like we can just drop the fini() call since the fence signaller side will already call this for us.
There are known mysterious splats with device going to sleep even with an rpm ref, and this could be one candidate.
v2 (Matt B): - Prefer warning if we detect double fini()
(cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183)