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

vsock/virtio: fix accept queue count leak on transport mismatch

virtiotransportrecvlisten() calls skacceptqadded() before vsockassigntransport(). If vsockassigntransport() fails or selects a different transport, the error path returns without calling skacceptqremoved(), permanently incrementing skackbacklog.

After approximately backlog+1 such failures, skacceptqisfull() returns true, causing the listener to reject all new connections.

Fix by moving skacceptqadded() to after the transport validation, matching the pattern used by vmcitransport and hypervtransport.

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

net: cpswnew: Fix potential unregister of netdev that has not been registered yet

If an error occurs during registernetdev() for the first MAC in cpswregisterports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpswunregisterports() to attempt unregistering the second MAC. To address this, add a check for ndev->regstate before calling unregisternetdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.

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

NFC: pn533: bound the UART receive buffer

pn532receivebuf() appends every incoming byte to dev->recvskb and only resets the buffer after pn532uartrxisframe() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skbputu8() hits the tail limit.

Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532UARTSKBBUFFLEN.

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

nfc: pn533: allocate rx skb before consuming bytes

pn532receivebuf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recvskb and may already hand a complete frame to pn533recvframe() before allocating a fresh receive buffer.

If that allocskb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recvskb as NULL for the next receive callback. That breaks the receivebuf() accounting contract and can also lead to a NULL dereference on the next skbputu8().

Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.

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

bonding: provide a net pointer to skbflowdissect()

After 3cbf4ffba5ee ("net: plumb network namespace into skbflowdissect") we have to provide a net pointer to skbflowdissect(), either via skb->dev, skb->sk, or a user provided pointer.

In the following case, syzbot was able to cook a bare skb.

WARNING: net/core/flowdissector.c:1131 at skbflowdissect+0xb57/0x68b0 net/core/flowdissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace: <TASK> bondflowdissect drivers/net/bonding/bondmain.c:4093 [inline] bondxmithash+0x2d7/0xba0 drivers/net/bonding/bondmain.c:4157 bondxmithashxdp drivers/net/bonding/bondmain.c:4208 [inline] bondxdpxmit3adxorslaveget drivers/net/bonding/bondmain.c:5139 [inline] bondxdpgetxmitslave+0x1fd/0x710 drivers/net/bonding/bondmain.c:5515 xdpmasterredirect+0x13f/0x2c0 net/core/filter.c:4388 bpfprogrunxdp include/net/xdp.h:700 [inline] bpftestrun+0x6b2/0x7d0 net/bpf/testrun.c:421 bpfprogtestrunxdp+0x795/0x10e0 net/bpf/testrun.c:1390 bpfprogtestrun+0x2c7/0x340 kernel/bpf/syscall.c:4703 sysbpf+0x562/0x860 kernel/bpf/syscall.c:6182 dosysbpf kernel/bpf/syscall.c:6274 [inline] sesysbpf kernel/bpf/syscall.c:6272 [inline] x64sysbpf+0x7c/0x90 kernel/bpf/syscall.c:6272 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xec/0xf80 arch/x86/entry/syscall64.c:94

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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:

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:

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:

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:

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.