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

drm/amdgpu: fix zero-size GDS range init on RDNA4

RDNA4 (GFX 12) hardware removes the GDS, GWS, and OA on-chip memory resources. The gfxv120 initialisation code correctly leaves adev->gds.gdssize, adev->gds.gwssize, and adev->gds.oasize at zero to reflect this.

amdgputtminit() unconditionally calls amdgputtminitonchip() for each of these resources regardless of size. When the size is zero, amdgputtminitonchip() forwards the call to ttmrangemaninit(), which calls drmmminit(mm, 0, 0). drmmminit() immediately fires DRMMMBUGON(start + size <= start) -- trivially true when size is zero -- crashing the kernel during modprobe of amdgpu on an RX 9070 XT.

Guard against this by returning 0 early from amdgputtminitonchip() when sizeinpage is zero. This skips TTM resource manager registration for hardware resources that are absent, without affecting any other GPU type.

DRMMMBUGON() only asserts if CONFIGDRMDEBUGMM is enabled in the kernel config. This is apparently rarely enabled as these chips have been in the market for over a year and this issue was only reported now.

Oops-Analysis: http://oops.fenrus.org/reports/bugzilla.korg/221376/report.html (cherry picked from commit 5719ce5865279cad4fd5f01011fe037168503f2d)

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

octeontx2-af: Fix PF driver crash with kexec kernel booting

During a kexec reboot the hardware is not power-cycled, so AF state from the old kernel can persist into the new kernel. When AF and PF drivers are built as modules, the PF driver may probe before AF reinitializes the hardware.

The PF driver treats the RVUM block revision as an indication that AF initialization is complete. If this value is left uncleared at shutdown, PF may incorrectly assume AF is ready and access stale hardware state, leading to a crash.

Clear the RVUM block revision during AF shutdown to avoid PF mis-detecting AF readiness after kexec.

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

tipc: fix divide-by-zero in tipcskfilterconnect()

A user can set conntimeout to any value via setsockopt(TIPCCONNTIMEOUT), including values less than 4. When a SYN is rejected with TIPCERROVERLOAD and the retry path in tipcskfilterconnect() executes:

delay %= (tsk->conntimeout / 4);

If conntimeout is in the range [0, 3], the integer division yields 0, and the modulo operation triggers a divide-by-zero exception, causing a kernel oops/panic.

Fix this by clamping conntimeout to a minimum of 4 at the point of use in tipcskfilterconnect().

Oops: divide error: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+ RIP: 0010:tipcskfilterrcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362) Call Trace: tipcskbacklogrcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406) releasesock (include/net/sock.h:1185 net/core/sock.c:3213) releasesock (net/core/sock.c:3797) tipcconnect (net/tipc/socket.c:2570) sysconnect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)

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

drm/ioc32: stop speculation on the drmcompatioctl path

The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling arrayindexnospec() on the index to the function pointer list.

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

spi: use generic driveroverride infrastructure

When a driver is probed through driverattach(), the bus' match() callback is called without the device lock held, thus accessing the driveroverride field without a lock, which can cause a UAF.

Fix this by using the driver-core driveroverride infrastructure taking care of proper locking internally.

Note that calling match() from driverattach() without the device lock held is intentional. [1]

Also note that we do not enable the driveroverride feature of struct bustype, as SPI - in contrast to most other buses - passes "" to sysfsemit() when the driveroverride pointer is NULL. Thus, printing "\n" instead of "(null)\n".

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

tty: serial: samsungtty: Fix a memory leak in s3c24xxserialgetclk() when iterating clk

When the best clk is searched, we iterate over all possible clk.

If we find a better match, the previous one, if any, needs to be freed. If a better match has already been found, we still need to free the new one, otherwise it leaks.

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

bcache: Fix bchbtreenodealloc to make the failure behavior consistent

In some specific situations, the return value of bchbtreenodealloc may be NULL. This may lead to a potential NULL pointer dereference in caller function like a calling chain : btreesplit->bchbtreenodealloc->bchbtreenodealloc.

Fix it by initializing the return value in bchbtreenodealloc.

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

btrfs: output extra debug info if we failed to find an inline backref

[BUG] Syzbot reported several warning triggered inside lookupinlineextentbackref().

[CAUSE] As usual, the reproducer doesn't reliably trigger locally here, but at least we know the WARNON() is triggered when an inline backref can not be found, and it can only be triggered when @insert is true. (I.e. inserting a new inline backref, which means the backref should already exist)

[ENHANCEMENT] After the WARNON(), dump all the parameters and the extent tree leaf to help debug.

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

net: cdcncm: Deal with too low values of dwNtbOutMaxSize

Currently in cdcncmchecktxmax(), if dwNtbOutMaxSize is lower than the calculated "min" value, but greater than zero, the logic sets txmax to dwNtbOutMaxSize. This is then used to allocate a new SKB in cdcncmfilltxframe() where all the data is handled.

For small values of dwNtbOutMaxSize the memory allocated during allocskb(dwNtbOutMaxSize, GFPATOMIC) will have the same size, due to how size is aligned at alloc time: size = SKBDATAALIGN(size); size += SKBDATAALIGN(sizeof(struct skbsharedinfo)); Thus we hit the same bug that we tried to squash with commit 2be6d4d16a084 ("net: cdcncm: Allow for dwNtbOutMaxSize to be unset or zero")

Low values of dwNtbOutMaxSize do not cause an issue presently because at allocskb() time more memory (512b) is allocated than required for the SKB headers alone (320b), leaving some space (512b - 320b = 192b) for CDC data (172b).

However, if more elements (for example 3 x u64 = [24b]) were added to one of the SKB header structs, say 'struct skbsharedinfo', increasing its original size (320b [320b aligned]) to something larger (344b [384b aligned]), then suddenly the CDC data (172b) no longer fits in the spare SKB data area (512b - 384b = 128b).

Consequently the SKB bounds checking semantics fails and panics:

skbuff: skboverpanic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:113! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 Workqueue: mld mldifcwork RIP: 0010:skbpanic net/core/skbuff.c:113 [inline] RIP: 0010:skboverpanic+0x14c/0x150 net/core/skbuff.c:118 [snip] Call Trace: <TASK> skbput+0x151/0x210 net/core/skbuff.c:2047 skbputzero include/linux/skbuff.h:2422 [inline] cdcncmndp16 drivers/net/usb/cdcncm.c:1131 [inline] cdcncmfilltxframe+0x11ab/0x3da0 drivers/net/usb/cdcncm.c:1308 cdcncmtxfixup+0xa3/0x100

Deal with too low values of dwNtbOutMaxSize, clamp it in the range [USBCDCNCMNTBMINOUTSIZE, CDCNCMNTBMAXSIZETX]. We ensure enough data space is allocated to handle CDC data by making sure dwNtbOutMaxSize is not smaller than USBCDCNCMNTBMINOUTSIZE.

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

spi: bcm-qspi: return error if neither hifmspi nor mspi is available

If neither a "hifmspi" nor "mspi" resource is present, the driver will just early exit in probe but still return success. Apart from not doing anything meaningful, this would then also lead to a null pointer access on removal, as platformgetdrvdata() would return NULL, which it would then try to dereference when trying to unregister the spi master.

Fix this by unconditionally calling devmioremapresource(), as it can handle a NULL res and will then return a viable ERRPTR() if we get one.

The "return 0;" was previously a "goto qspiresourceerr;" where then ret was returned, but since ret was still initialized to 0 at this place this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix use-after-free on unbind"). The issue was not introduced by this commit, only made more obvious.

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:

usb: host: xhci: Fix potential memory leak in xhciallocstreaminfo()

xhciallocstreaminfo() allocates stream context array for streaminfo ->streamctxarray with xhciallocstreamctx(). When some error occurs, streaminfo->streamctxarray is not released, which will lead to a memory leak.

We can fix it by releasing the streaminfo->streamctxarray with xhcifreestreamctx() on the error path to avoid the potential memory leak.

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:

drm/amd/display: Fix potential null-deref in dmresume

[Why] Fixing smatch error: dmresume() error: we previously assumed 'aconnector->dclink' could be null

[How] Check if dclink null at the beginning of the loop, so further checks can be dropped.

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

fbdev: omapfb: lcdmipid: Fix an error handling path in mipidspiprobe()

If 'mipiddetect()' fails, we must free 'md' to avoid a memory leak.

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

ALSA: ac97: Fix possible NULL dereference in sndac97mixer

smatch error: sound/pci/ac97/ac97codec.c:2354 sndac97mixer() error: we previously assumed 'rac97' could be null (see line 2072)

remove redundant assignment, return error if rac97 is NULL.

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

media: radio-shark: Add endpoint checks

The syzbot fuzzer was able to provoke a WARNING from the radio-shark2 driver:

------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usbsubmiturb+0xed2/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: usbhubwq hubevent RIP: 0010:usbsubmiturb+0xed2/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edac RBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001 R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200 FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> usbstartwaiturb+0x101/0x4b0 drivers/usb/core/message.c:58 usbbulkmsg+0x226/0x550 drivers/usb/core/message.c:387 sharkwritereg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88 ...

The problem was caused by the fact that the driver does not check whether the endpoints it uses are actually present and have the appropriate types. This can be fixed by adding a simple check of these endpoints (and similarly for the radio-shark driver).

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

wifi: ath9k: hifusb: fix memory leak of remainskbs

hifdev->remainskb is allocated and used exclusively in ath9khifusbrxstream(). It is implied that an allocated remainskb is processed and subsequently freed (in error paths) only during the next call of ath9khifusbrxstream().

So, if the urbs are deallocated between those two calls due to the device deinitialization or suspend, it is possible that ath9khifusbrxstream() is not called next time and the allocated remainskb is leaked. Our local Syzkaller instance was able to trigger that.

remainskb makes sense when receiving two consecutive urbs which are logically linked together, i.e. a specific data field from the first skb indicates a cached skb to be allocated, memcpy'd with some data and subsequently processed in the next call to ath9khifusbrxstream(). Urbs deallocation supposedly makes that link irrelevant so we need to free the cached skb in those cases.

Fix the leak by introducing a function to explicitly free remainskb (if it is not NULL) when the rx urbs have been deallocated. remainskb is NULL when it has not been allocated at all (hifdev struct is kzalloced) or when it has been processed in next call to ath9khifusbrxstream().

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

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

wifi: ath6kl: reduce WARN to devdbg() in callback

The warn is triggered on a known race condition, documented in the code above the test, that is correctly handled. Using WARN() hinders automated testing. Reducing severity.

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

media: i2c: ov772x: Fix memleak in ov772xprobe()

A memory leak was reported when testing ov772x with bpf mock device:

AssertionError: unreferenced object 0xffff888109afa7a8 (size 8): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 8 bytes): 80 22 88 15 81 88 ff ff ."...... backtrace: [<000000009990b438>] kmallocnode+0x44/0x1b0 [<000000009e32f7d7>] kvmallocnode+0x34/0x180 [<00000000faf48134>] v4l2ctrlhandlerinitclass+0x11d/0x180 [videodev] [<00000000da376937>] ov772xprobe+0x1c3/0x68c [ov772x] [<000000003f0d225e>] i2cdeviceprobe+0x28d/0x680 [<00000000e0b6db89>] reallyprobe+0x17c/0x3f0 [<000000001b19fcee>] driverprobedevice+0xe3/0x170 [<0000000048370519>] driverprobedevice+0x49/0x120 [<000000005ead07a0>] deviceattachdriver+0xf7/0x150 [<0000000043f452b8>] busforeachdrv+0x114/0x180 [<00000000358e5596>] deviceattach+0x1e5/0x2d0 [<0000000043f83c5d>] busprobedevice+0x126/0x140 [<00000000ee0f3046>] deviceadd+0x810/0x1130 [<00000000e0278184>] i2cnewclientdevice+0x359/0x4f0 [<0000000070baf34f>] ofi2cregisterdevice+0xf1/0x110 [<00000000a9f2159d>] ofi2cnotify+0x100/0x160 unreferenced object 0xffff888119825c00 (size 256): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 32 bytes): 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^...... 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\...... backtrace: [<000000009990b438>] kmallocnode+0x44/0x1b0 [<000000009e32f7d7>] kvmallocnode+0x34/0x180 [<0000000073d88e0b>] v4l2ctrlnew.cold+0x19b/0x86f [videodev] [<00000000b1f576fb>] v4l2ctrlnewstd+0x16f/0x210 [videodev] [<00000000caf7ac99>] ov772xprobe+0x1fa/0x68c [ov772x] [<000000003f0d225e>] i2cdeviceprobe+0x28d/0x680 [<00000000e0b6db89>] reallyprobe+0x17c/0x3f0 [<000000001b19fcee>] driverprobedevice+0xe3/0x170 [<0000000048370519>] driverprobedevice+0x49/0x120 [<000000005ead07a0>] deviceattachdriver+0xf7/0x150 [<0000000043f452b8>] busforeachdrv+0x114/0x180 [<00000000358e5596>] deviceattach+0x1e5/0x2d0 [<0000000043f83c5d>] busprobedevice+0x126/0x140 [<00000000ee0f3046>] deviceadd+0x810/0x1130 [<00000000e0278184>] i2cnewclientdevice+0x359/0x4f0 [<0000000070baf34f>] ofi2cregisterdevice+0xf1/0x110

The reason is that if priv->hdl.error is set, ov772xprobe() jumps to the errormutexdestroy without doing v4l2ctrlhandlerfree(), and all resources allocated in v4l2ctrlhandlerinit() and v4l2ctrlnewstd() are leaked.

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

mm/swap: fix swapinfostruct race between swapoff and getswappages()

The si->lock must be held when deleting the si from the available list. Otherwise, another thread can re-add the si to the available list, which can lead to memory corruption. The only place we have found where this happens is in the swapoff path. This case can be described as below:

core 0 core 1 swapoff

delfromavaillist(si) waiting

try lock si->lock acquire swapavaillock and re-add si into swapavailhead

acquire si->lock but missing si already being added again, and continuing to clear SWPWRITEOK, etc.

It can be easily found that a massive warning messages can be triggered inside getswappages() by some special cases, for example, we call madvise(MADVPAGEOUT) on blocks of touched memory concurrently, meanwhile, run much swapon-swapoff operations (e.g. stress-ng-swap).

However, in the worst case, panic can be caused by the above scene. In swapoff(), the memory used by si could be kept in swapinfo[] after turning off a swap. This means memory corruption will not be caused immediately until allocated and reset for a new swap in the swapon path. A panic message caused: (with CONFIGPLISTDEBUG enabled)

------------[ cut here ]------------ top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451a prev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8d next: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451a WARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plistcheckprevnextnode+0x50/0x70 Modules linked in: rfkill(E) crct10difce(E)... CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+ Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) pc : plistcheckprevnextnode+0x50/0x70 lr : plistcheckprevnextnode+0x50/0x70 sp : ffff0018009d3c30 x29: ffff0018009d3c40 x28: ffff800011b32a98 x27: 0000000000000000 x26: ffff001803908000 x25: ffff8000128ea088 x24: ffff800011b32a48 x23: 0000000000000028 x22: ffff001800875c00 x21: ffff800010f9e520 x20: ffff001800875c00 x19: ffff001800fdc6e0 x18: 0000000000000030 x17: 0000000000000000 x16: 0000000000000000 x15: 0736076307640766 x14: 0730073007380731 x13: 0736076307640766 x12: 0730073007380731 x11: 000000000004058d x10: 0000000085a85b76 x9 : ffff8000101436e4 x8 : ffff800011c8ce08 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff0017df9ed338 x4 : 0000000000000001 x3 : ffff8017ce62a000 x2 : ffff0017df9ed340 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: plistcheckprevnextnode+0x50/0x70 plistcheckhead+0x80/0xf0 plistadd+0x28/0x140 addtoavaillist+0x9c/0xf0 enableswapinfo+0x78/0xb4 dosysswapon+0x918/0xa10 arm64sysswapon+0x20/0x30 el0svccommon+0x8c/0x220 doel0svc+0x2c/0x90 el0svc+0x1c/0x30 el0synchandler+0xa8/0xb0 el0sync+0x148/0x180 irq event stamp: 2082270

Now, si->lock locked before calling 'delfromavaillist()' to make sure other thread see the si had been deleted and SWPWRITEOK cleared together, will not reinsert again.

This problem exists in versions after stable 5.10.y.

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:

tipc: fix an information leak in tipctopsrvkernsubscr

Use a 8-byte write to initialize sub.usrhandle in tipctopsrvkernsubscr(), otherwise four bytes remain uninitialized when issuing setsockopt(..., SOLTIPC, ...). This resulted in an infoleak reported by KMSAN when the packet was received:

===================================================== BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/ioviter.c:169 instrumentcopytouser ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/ioviter.c:169 copytoiter+0x5c0/0x20a0 lib/ioviter.c:527 copytoiter ./include/linux/uio.h:176 simplecopytoiter+0x64/0xa0 net/core/datagram.c:513 skbdatagramiter+0x123/0xdc0 net/core/datagram.c:419 skbcopydatagramiter+0x58/0x200 net/core/datagram.c:527 skbcopydatagrammsg ./include/linux/skbuff.h:3903 packetrecvmsg+0x521/0x1e70 net/packet/afpacket.c:3469 sysrecvmsg+0x2c4/0x810 net/socket.c:? sysrecvmsg+0x217/0x840 net/socket.c:2743 sysrecvmsg net/socket.c:2773 dosysrecvmsg net/socket.c:2783 sesysrecvmsg net/socket.c:2780 x64sysrecvmsg+0x364/0x540 net/socket.c:2780 dosyscallx64 arch/x86/entry/common.c:50 dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd arch/x86/entry/entry64.S:120

...

Uninit was stored to memory at: tipcsubsubscribe+0x42d/0xb50 net/tipc/subscr.c:156 tipcconnrcvsub+0x246/0x620 net/tipc/topsrv.c:375 tipctopsrvkernsubscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipcgroupcreate+0x4e7/0x7d0 net/tipc/group.c:190 tipcskjoin+0x2a8/0x770 net/tipc/socket.c:3084 tipcsetsockopt+0xae5/0xe40 net/tipc/socket.c:3201 syssetsockopt+0x87f/0xdc0 net/socket.c:2252 dosyssetsockopt net/socket.c:2263 sesyssetsockopt net/socket.c:2260 x64syssetsockopt+0xe0/0x160 net/socket.c:2260 dosyscallx64 arch/x86/entry/common.c:50 dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd arch/x86/entry/entry64.S:120

Local variable sub created at: tipctopsrvkernsubscr+0x57/0x400 net/tipc/topsrv.c:562 tipcgroupcreate+0x4e7/0x7d0 net/tipc/group.c:190

Bytes 84-87 of 88 are uninitialized Memory access of size 88 starts at ffff88801ed57cd0 Data copied to user address 0000000020000400 ... =====================================================

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:

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:

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.

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

drm/radeon: Fix PCI device refcount leak in radeonatrmgetbios()

As comment of pcigetclass() says, it returns a pcidevice with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL.

If we break the loop in radeonatrmgetbios() with 'pdev' not NULL, we need to call pcidevput() to decrease the refcount. Add the missing pcidevput() to avoid refcount leak.

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

nilfs2: replace WARNONs by nilfserror for checkpoint acquisition failure

If creation or finalization of a checkpoint fails due to anomalies in the checkpoint metadata on disk, a kernel warning is generated.

This patch replaces the WARNONs by nilfserror, so that a kernel, booted with paniconwarn, does not panic. A nilfserror is appropriate here to handle the abnormal filesystem condition.

This also replaces the detected error codes with an I/O error so that neither of the internal error codes is returned to callers.