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

gpio: rockchip: teardown bugs and resource leaks

Address several teardown issues and resource leaks in the driver's remove path and error handling:

1. Debounce clock reference leak: The debounce clock (bank->dbclk) is obtained using ofclkget() which increments the clock's reference count, but clkput() is never called. Register a devm action to cleanly release it on unbind. Note that ofclkget(..., 1) remains necessary over devmclkget() because the DT binding does not define clock-names, precluding name-based lookup.

2. Unregistered chained IRQ handler: The chained IRQ handler is not disconnected in remove(). If a stray interrupt fires after the driver is removed, the kernel attempts to execute a stale handler, leading to a panic. Fix this by clearing the handler in remove().

3. IRQ domain leak: The linear IRQ domain and its generic chips are allocated manually during probe but never removed. Remove the IRQ domain during driver teardown to free the associated generic chips and mappings.

[Bartosz: don't emit an error message on devres allocation failure]

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

gpio: rockchip: fix generic IRQ chip leak on remove

The driver allocates domain generic chips using irqallocdomaingenericchips() during probe. However, on driver remove/teardown, the generic chips are not automatically freed when the IRQ domain is removed because the domain flags do not include IRQDOMAINFLAGDESTROYGC.

This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global gclist and may later be visited by generic IRQ chip suspend, resume, or shutdown callbacks after the GPIO bank has been removed, potentially resulting in a use-after-free and kernel crash.

Fix the resource leak by explicitly calling irqdomainremovegenericchips() before removing the IRQ domain in rockchipgpioremove().

bpf, sockmap: Fix afunix iter deadlock

futex: Prevent lockup in requeue-PI during signal/ timeout wakeup

afunix: Reject SIOCATMARK on non-stream sockets

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

scsi: sd: fix missing putdisk() when deviceadd(&diskdev) fails

If deviceadd(&sdkp->diskdev) fails, putdevice() runs scsidiskrelease(), which frees the scsidisk but leaves the gendisk referenced. The deviceadddisk() error path in sdprobe() calls putdisk(gd); call putdisk(gd) here to mirror that cleanup.

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

net: mctp: ensure our nlmsg responses are initialised

Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTMGETNEIGH will return uninitalised data in the pad bytes of the ndmsg data.

Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.

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

fs/ntfs3: prevent infinite loops caused by the next valid being the same

When processing valid within the range [valid : pos), if valid cannot be retrieved correctly, for example, if the retrieved valid value is always the same, this can trigger a potential infinite loop, similar to the hung problem reported by syzbot [1].

Adding a check for the valid value within the loop body, and terminating the loop and returning -EINVAL if the value is the same as the current value, can prevent this.

[1] INFO: task syz.4.21:6056 blocked for more than 143 seconds. Call Trace: rwbasewritelock+0x14f/0x750 kernel/locking/rwbasert.c:244 inodelock include/linux/fs.h:1027 [inline] ntfsfilewriteiter+0xe6/0x870 fs/ntfs3/file.c:1284

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

net: ethernet: xscale: Check for PTP support properly

In ixp4xxgettsinfo() ixp46xptpfind() is called unconditionally despite this feature only existing on ixp46x, leading to the following splat from tcpdump:

root@OpenWrt:~# tcpdump -vv -X -i eth0 (...) Unable to handle kernel NULL pointer dereference at virtual address 00000238 when read (...) Call trace: ptpclockindex from ixp46xptpfind+0x1c/0x38 ixp46xptpfind from ixp4xxgettsinfo+0x4c/0x64 ixp4xxgettsinfo from ethtoolgettsinfo+0x90/0x108 ethtoolgettsinfo from devethtool+0xa00/0x2648 devethtool from devethtool+0x160/0x234 devethtool from devioctl+0x2cc/0x460 devioctl from sockioctl+0x1ec/0x524 sockioctl from sysioctl+0x51c/0xa94 sysioctl from retfastsyscall+0x0/0x44 (...) Segmentation fault

Check for ixp46x in ixp46xptpfind() before trying to set up PTP to avoid this.

To avoid altering the returned error code from ixp4xxhwtstampset() which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP from ixp4xxhwtstampset() if ixp46xptpfind() fails no matter the error code. The helper function ixp46xptpfind() helper returns -ENODEV.

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

drm/vc4: platformgetirqbyname() returns an int

platformgetirqbyname() will return a negative value if an error happens, so it should be checked and not just passed directly into devmrequestthreadedirq() hoping all will be ok.

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

ext4: always drain queued discard work in ext4mbrelease()

While reviewing recent ext4 patch[1], Sashiko raised the following concern[2]:

If the filesystem is initially mounted with the discard option, deleting files will populate sbi->sdiscardlist and queue sdiscardwork. If it is then remounted with nodiscard, the EXT4MOUNTDISCARD flag is cleared, but the pending sdiscardwork is neither cancelled nor flushed.

[1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/ [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev

The concern was valid, but it had nothing to do with the patch[1]. One of the problems with Sashiko in its current (early) form is that it will detect pre-existing issues and report it as a problem with the patch that it is reviewing.

In practice, it would be hard to hit deliberately (unless you are a malicious syzkaller fuzzer), since it would involve mounting the file system with -o discard, and then deleting a large number of files, remounting the file system with -o nodiscard, and then immediately unmounting the file system before the queued discard work has a change to drain on its own.

Fix it because it's a real bug, and to avoid Sashiko from raising this concern when analyzing future patches to mballoc.c.

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

ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc

The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbddecodenegTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbdnegtokenalloc() allocates conn->mechToken immediately via kmemdupnul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE.

decodenegotiationtoken() then sets conn->usespnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2sesssetup() is gated on usespnego:

if (conn->usespnego && conn->mechToken) { kfree(conn->mechToken); conn->mechToken = NULL; }

so the kfree is skipped, causing the mechToken to never be freed.

This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated.

Fix this up by not checking check for usespnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbdconnfree() incase some other failure path forgot to free it.

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

smb: server: make use of smbdirectsocket.sendio.bcredits

It turns out that our code will corrupt the stream of reassabled data transfer messages when we trigger an immendiate (empty) send.

In order to fix this we'll have a single 'batch' credit per connection. And code getting that credit is free to use as much messages until remaininglength reaches 0, then the batch credit it given back and the next logical send can happen.

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

ksmbd: use volume UUID in FSOBJECTIDINFORMATION

Use sb->suuid for a proper volume identifier as the primary choice. For filesystems that do not provide a UUID, fall back to stfs.ffsid obtained from vfsstatfs().

fs: ntfs3: fix infinite loop triggered by zero-sized ATTRLIST

fs: ntfs3: check return value of indxfind to avoid infinite loop

fs: ntfs3: fix infinite loop in attrloadrunsrange on inconsistent metadata

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

ipv6: annotate data-race in ndiscrouterdiscovery()

syzbot found that ndiscrouterdiscovery() could read and write in6dev->ramtu without holding a lock [1]

This looks fine, IFLAINET6RAMTU is best effort.

Add READONCE()/WRITEONCE() to document the race.

Note that we might also reject illegal MTU values (mtu < IPV6MINMTU || mtu > skb->dev->mtu) in a future patch.

[1] BUG: KCSAN: data-race in ndiscrouterdiscovery / ndiscrouterdiscovery

read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndiscrouterdiscovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndiscrcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6protocoldeliverrcu+0xb2a/0x10d0 net/ipv6/ip6input.c:438 ip6inputfinish+0xf0/0x1d0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] ip6input+0x5e/0x140 net/ipv6/ip6input.c:500 ip6mcinput+0x27c/0x470 net/ipv6/ip6input.c:590 dstinput include/net/dst.h:474 [inline] ip6rcvfinish+0x336/0x340 net/ipv6/ip6input.c:79 ...

write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndiscrouterdiscovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndiscrcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6protocoldeliverrcu+0xb2a/0x10d0 net/ipv6/ip6input.c:438 ip6inputfinish+0xf0/0x1d0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] ip6input+0x5e/0x140 net/ipv6/ip6input.c:500 ip6mcinput+0x27c/0x470 net/ipv6/ip6input.c:590 dstinput include/net/dst.h:474 [inline] ip6rcvfinish+0x336/0x340 net/ipv6/ip6input.c:79 ...

value changed: 0x00000000 -> 0xe5400659

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

ksmbd: smbd: fix dmaunmapsg() nents

The dmaunmapsg() functions should be called with the same nents as the dmamapsg(), not the value the map function returned.

dmaengine: idxd: fix device leaks on compat bind and unbind

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

ASoC: codecs: wcd938x: fix missing mbhc init error handling

MBHC initialisation can fail so add the missing error handling to avoid dereferencing an error pointer when later configuring the jack:

Unable to handle kernel paging request at virtual address fffffffffffffff8

pc : wcdmbhcstart+0x28/0x380 [sndsocwcdmbhc] lr : wcd938xcodecsetjack+0x28/0x48 [sndsocwcd938x]

Call trace: wcdmbhcstart+0x28/0x380 [sndsocwcdmbhc] wcd938xcodecsetjack+0x28/0x48 [sndsocwcd938x] sndsoccomponentsetjack+0x28/0x8c [sndsoccore] qcomsndwcdjacksetup+0x7c/0x19c [sndsocqcomcommon] sc8280xpsndinit+0x20/0x2c [sndsocsc8280xp] sndsoclinkinit+0x28/0x90 [sndsoccore] sndsocbindcard+0x628/0xbfc [sndsoccore] sndsocregistercard+0xec/0x104 [sndsoccore] devmsndsocregistercard+0x4c/0xa4 [sndsoccore] sc8280xpplatformprobe+0xf0/0x108 [sndsocsc8280xp]

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

fs/ntfs3: Fix memory leak on ntfsfillsuper() error path

syzbot reported kmemleak as below:

BUG: memory leak unreferenced object 0xffff8880122f1540 (size 32): comm "a.out", pid 6664, jiffies 4294939771 (age 25.500s) 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 ed ff ed ff 00 00 00 00 ................ backtrace: [<ffffffff81b16052>] ntfsinitfscontext+0x22/0x1c0 [<ffffffff8164aaa7>] allocfscontext+0x217/0x430 [<ffffffff81626dd4>] pathmount+0x704/0x1080 [<ffffffff81627e7c>] x64sysmount+0x18c/0x1d0 [<ffffffff84593e14>] dosyscall64+0x34/0xb0 [<ffffffff84600087>] entrySYSCALL64afterhwframe+0x63/0xcd

This patch fixes this issue by freeing mount options on error path of ntfsfillsuper().

bpf: Tell memcg to use allowspinning=false path in bpftimerinit()

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

clk: mediatek: fix ofiomap memory leak

Smatch reports: drivers/clk/mediatek/clk-mtk.c:583 mtkclksimpleprobe() warn: 'base' from ofiomap() not released on lines: 496.

This problem was also found in linux-next. In mtkclksimpleprobe(), base is not released when handling errors if clkdata is not existed, which may cause a leak. So freebase should be added here to release base.

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

block: be a bit more careful in checking for NULL bdev while polling

Wei reports a crash with an application using polled IO:

PGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0 Oops: 0000 [#1] SMP CPU: 0 PID: 21915 Comm: iocore0 Kdump: loaded Tainted: G S 5.12.0-0fbk12clang7346g1bb6f2e7058f #1 Hardware name: Wiwynn Delta Lake MP T8/Delta Lake-Class2, BIOS Y3DLM08 04/10/2022 RIP: 0010:biopoll+0x25/0x200 Code: 0f 1f 44 00 00 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 <48> 8b 80 70 02 00 00 4c 8b 70 50 8b 6f 34 31 db 83 fd ff 75 25 65 RSP: 0018:ffffc90005fafdf8 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600 RDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140 RBP: ffff88849964df78 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00 R13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001 FS: 00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: iocbbioiopoll+0x1d/0x30 iodoiopoll+0xac/0x250 sesysiouringenter+0x3c5/0x5a0 ? x64syswrite+0x89/0xd0 dosyscall64+0x2d/0x40 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x94f225d Code: 24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 01 00 00 0f 05 <85> c0 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7 RSP: 002b:00007fd194ffcd88 EFLAGS: 00000202 ORIGRAX: 00000000000001aa RAX: ffffffffffffffda RBX: 00007fd194ffcdc0 RCX: 00000000094f225d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007 RBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008 R10: 0000000000000001 R11: 0000000000000202 R12: 00007fd269d68030 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000

which is due to bio->bibdev being NULL. This can happen if we have two tasks doing polled IO, and task B ends up completing IO from task A if they are sharing a poll queue. If task B completes the IO and puts the bio into our cache, then it can allocate that bio again before task A is done polling for it. As that would necessitate a preempt between the two tasks, it's enough to just be a bit more careful in checking for whether or not bio->bibdev is NULL.

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

fs/ntfs3: Enhance sanity check while generating attrlist

nicreateattrlist uses WARNON to catch error cases while generating attribute list, which only prints out stack trace and may not be enough. This repalces them with more proper error handling flow.

[ 59.666332] BUG: kernel NULL pointer dereference, address: 000000000000000e [ 59.673268] #PF: supervisor read access in kernel mode [ 59.678354] #PF: errorcode(0x0000) - not-present page [ 59.682831] PGD 8000000005ff1067 P4D 8000000005ff1067 PUD 7dee067 PMD 0 [ 59.688556] Oops: 0000 [#1] PREEMPT SMP KASAN PTI [ 59.692642] CPU: 0 PID: 198 Comm: poc Tainted: G B W 6.2.0-rc1+ #4 [ 59.698868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 59.708795] RIP: 0010:nicreateattrlist+0x505/0x860 [ 59.713657] Code: 7e 10 e8 5e d0 d0 ff 45 0f b7 76 10 48 8d 7b 16 e8 00 d1 d0 ff 66 44 89 73 16 4d 8d 75 0e 4c 89 f7 e8 3f d0 d0 ff 4c 8d8 [ 59.731559] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282 [ 59.735691] RAX: 0000000000000001 RBX: ffff88800b7b5088 RCX: ffffffffb83079fe [ 59.741792] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffbb7f9fc0 [ 59.748423] RBP: ffff88800a56f3a8 R08: ffff88800b7b50a0 R09: fffffbfff76ff3f9 [ 59.754654] R10: ffffffffbb7f9fc7 R11: fffffbfff76ff3f8 R12: ffff88800b756180 [ 59.761552] R13: 0000000000000000 R14: 000000000000000e R15: 0000000000000050 [ 59.768323] FS: 00007feaa8c96440(0000) GS:ffff88806d400000(0000) knlGS:0000000000000000 [ 59.776027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 59.781395] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 00000000000006f0 [ 59.787607] Call Trace: [ 59.790271] <TASK> [ 59.792488] ? pfxnicreateattrlist+0x10/0x10 [ 59.797235] ? kerneltextaddress+0xd3/0xe0 [ 59.800856] ? unwindgetreturnaddress+0x3e/0x60 [ 59.805101] ? kasancheckwrite+0x18/0x20 [ 59.809296] ? preemptcountsub+0x1c/0xd0 [ 59.813421] niinsattrext+0x52c/0x5c0 [ 59.817034] ? pfxniinsattrext+0x10/0x10 [ 59.821926] ? vfssetxattr+0x121/0x170 [ 59.825718] ? vfssetxattrnoperm+0x97/0x300 [ 59.829562] ? vfssetxattrlocked+0x145/0x170 [ 59.833987] ? vfssetxattr+0x137/0x2a0 [ 59.836732] ? dosetxattr+0xce/0x150 [ 59.839807] ? setxattr+0x126/0x140 [ 59.842353] ? pathsetxattr+0x164/0x180 [ 59.845275] ? x64syssetxattr+0x71/0x90 [ 59.848838] ? dosyscall64+0x3f/0x90 [ 59.851898] ? entrySYSCALL64afterhwframe+0x72/0xdc [ 59.857046] ? stackdepotsave+0x17/0x20 [ 59.860299] niinsertattr+0x1ba/0x420 [ 59.863104] ? pfxniinsertattr+0x10/0x10 [ 59.867069] ? preemptcountsub+0x1c/0xd0 [ 59.869897] ? rawspinunlockirqrestore+0x2b/0x50 [ 59.874088] ? createobject+0x3ae/0x5d0 [ 59.877865] niinsertresident+0xc4/0x1c0 [ 59.881430] ? pfxniinsertresident+0x10/0x10 [ 59.886355] ? kasansaveallocinfo+0x1f/0x30 [ 59.891117] ? kasankmalloc+0x8b/0xa0 [ 59.894383] ntfssetea+0x90d/0xbf0 [ 59.897703] ? pfxntfssetea+0x10/0x10 [ 59.901011] ? kerneltextaddress+0xd3/0xe0 [ 59.905308] ? kerneltextaddress+0x16/0x50 [ 59.909811] ? unwindgetreturnaddress+0x3e/0x60 [ 59.914898] ? pfxstacktraceconsumeentry+0x10/0x10 [ 59.920250] ? archstackwalk+0xa2/0x100 [ 59.924560] ? filterirqstacks+0x27/0x80 [ 59.928722] ntfssetxattr+0x405/0x440 [ 59.932512] ? pfxntfssetxattr+0x10/0x10 [ 59.936634] ? kvmallocnode+0x2d/0x120 [ 59.940378] ? kasansavestack+0x41/0x60 [ 59.943870] ? kasansavestack+0x2a/0x60 [ 59.947719] ? kasansettrack+0x29/0x40 [ 59.951417] ? kasansaveallocinfo+0x1f/0x30 [ 59.955733] ? kasankmalloc+0x8b/0xa0 [ 59.959598] ? kmallocnode+0x68/0x150 [ 59.963163] ? kvmallocnode+0x2d/0x120 [ 59.966490] ? vmemdupuser+0x2b/0xa0 ---truncated---

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

ext2/dax: Fix ext2setsize when len is page aligned

PAGEALIGN(x) macro gives the next highest value which is multiple of pagesize. But if x is already page aligned then it simply returns x. So, if x passed is 0 in daxzerorange() function, that means the length gets passed as 0 to ->iomapbegin().

In ext2 it then calls ext2getblocks -> maxblocks as 0 and hits bugon here in ext2getblocks(). BUGON(maxblocks == 0);

Instead we should be calling daxtruncatepage() here which takes care of it. i.e. it only calls daxzerorange if the offset is not page/block aligned.

This can be easily triggered with following on fsdax mounted pmem device.

dd if=/dev/zero of=file count=1 bs=512 truncate -s 0 file

[79.525838] EXT2-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk [79.529376] ext2 filesystem being mounted at /mnt1/test supports timestamps until 2038 (0x7fffffff) [93.793207] ------------[ cut here ]------------ [93.795102] kernel BUG at fs/ext2/inode.c:637! [93.796904] invalid opcode: 0000 [#1] PREEMPT SMP PTI [93.798659] CPU: 0 PID: 1192 Comm: truncate Not tainted 6.3.0-rc2-xfstests-00056-g131086faa369 #139 [93.806459] RIP: 0010:ext2getblocks.constprop.0+0x524/0x610 <...> [93.835298] Call Trace: [93.836253] <TASK> [93.837103] ? lockacquire+0xf8/0x110 [93.838479] ? dlookup+0x69/0xd0 [93.839779] ext2iomapbegin+0xa7/0x1c0 [93.841154] iomapiter+0xc7/0x150 [93.842425] daxzerorange+0x6e/0xa0 [93.843813] ext2setsize+0x176/0x1b0 [93.845164] ext2setattr+0x151/0x200 [93.846467] notifychange+0x341/0x4e0 [93.847805] ? lockacquire+0xf8/0x110 [93.849143] ? dotruncate+0x74/0xe0 [93.850452] ? dotruncate+0x84/0xe0 [93.851739] dotruncate+0x84/0xe0 [93.852974] dosysftruncate+0x2b4/0x2f0 [93.854404] dosyscall64+0x3f/0x90 [93.855789] entrySYSCALL64afterhwframe+0x72/0xdc

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

fs/ntfs3: Fix null-ptr-deref on inode->iop in ntfslookup()

Syzbot reported a null-ptr-deref bug:

ntfs3: loop0: Different NTFS' sector size (1024) and media sector size (512) ntfs3: loop0: Mark volume as dirty due to NTFS errors general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:dflagsforinode fs/dcache.c:1980 [inline] RIP: 0010:dadd+0x5ce/0x800 fs/dcache.c:2796 Call Trace: <TASK> dsplicealias+0x122/0x3b0 fs/dcache.c:3191 lookupopen fs/namei.c:3391 [inline] openlastlookups fs/namei.c:3481 [inline] pathopenat+0x10e6/0x2df0 fs/namei.c:3688 dofilpopen+0x264/0x4f0 fs/namei.c:3718 dosysopenat2+0x124/0x4e0 fs/open.c:1310 dosysopen fs/open.c:1326 [inline] dosysopen fs/open.c:1334 [inline] sesysopen fs/open.c:1330 [inline] x64sysopen+0x221/0x270 fs/open.c:1330 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

If the MFT record of ntfs inode is not a base record, inode->iop can be NULL. And a null-ptr-deref may happen:

ntfslookup() dirsearchu() # inode->iop is set to NULL dsplicealias() dadd() dflagsforinode() # inode->iop->getlink null-ptr-deref

Fix this by adding a Check on inode->iop before calling the dsplicealias() function.

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

fs/ntfs3: Add null pointer check to attrloadrunsvcn

Some metadata files are handled before MFT. This adds a null pointer check for some corner cases that could lead to NPD while reading these metadata files for a malformed NTFS image.

[ 240.190827] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 240.191583] #PF: supervisor read access in kernel mode [ 240.191956] #PF: errorcode(0x0000) - not-present page [ 240.192391] PGD 0 P4D 0 [ 240.192897] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 240.193805] CPU: 0 PID: 242 Comm: mount Tainted: G B 5.19.0+ #17 [ 240.194477] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 240.195152] RIP: 0010:nifindattr+0xae/0x300 [ 240.195679] Code: c8 48 c7 45 88 c0 4e 5e 86 c7 00 f1 f1 f1 f1 c7 40 04 00 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 e8 e2 d9f [ 240.196642] RSP: 0018:ffff88800812f690 EFLAGS: 00000286 [ 240.197019] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff85ef037a [ 240.197523] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff88e95f60 [ 240.197877] RBP: ffff88800812f738 R08: 0000000000000001 R09: fffffbfff11d2bed [ 240.198292] R10: ffffffff88e95f67 R11: fffffbfff11d2bec R12: 0000000000000000 [ 240.198647] R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000000 [ 240.199410] FS: 00007f233c33be40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 240.199895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 240.200314] CR2: 0000000000000158 CR3: 0000000004d32000 CR4: 00000000000006f0 [ 240.200839] Call Trace: [ 240.201104] <TASK> [ 240.201502] ? niloadmi+0x80/0x80 [ 240.202297] ? slaballoc+0x465/0x830 [ 240.202614] attrloadrunsvcn+0x8c/0x1a0 [ 240.202886] ? kasanslaballoc+0x32/0x90 [ 240.203157] ? attrdatawriteresident+0x250/0x250 [ 240.203543] miread+0x133/0x2c0 [ 240.203785] miget+0x70/0x140 [ 240.204012] niloadmiex+0xfa/0x190 [ 240.204346] ? nistd5+0x90/0x90 [ 240.204588] ? kasankmalloc+0x88/0xb0 [ 240.204859] nienumattrex+0xf1/0x1c0 [ 240.205107] ? nifnametype.part.0+0xd0/0xd0 [ 240.205600] ? ntfsloadattrlist+0xbe/0x300 [ 240.205864] ? ntfscmpnamescpu+0x125/0x180 [ 240.206157] ntfsiget5+0x56c/0x1870 [ 240.206510] ? ntfsgetblockbmap+0x70/0x70 [ 240.206776] ? kasankmalloc+0x88/0xb0 [ 240.207030] ? setblocksize+0x95/0x150 [ 240.207545] ntfsfillsuper+0xb8f/0x1e20 [ 240.207839] ? putntfs+0x1d0/0x1d0 [ 240.208069] ? vsprintf+0x20/0x20 [ 240.208467] ? mutexunlock+0x81/0xd0 [ 240.208846] ? setblocksize+0x95/0x150 [ 240.209221] gettreebdev+0x232/0x370 [ 240.209804] ? putntfs+0x1d0/0x1d0 [ 240.210519] ntfsfsgettree+0x15/0x20 [ 240.210991] vfsgettree+0x4c/0x130 [ 240.211455] pathmount+0x645/0xfd0 [ 240.211806] ? putname+0x80/0xa0 [ 240.212112] ? finishautomount+0x2e0/0x2e0 [ 240.212559] ? kmemcachefree+0x110/0x390 [ 240.212906] ? putname+0x80/0xa0 [ 240.213329] domount+0xd6/0xf0 [ 240.213829] ? pathmount+0xfd0/0xfd0 [ 240.214246] ? kasancheckwrite+0x14/0x20 [ 240.214774] x64sysmount+0xca/0x110 [ 240.215080] dosyscall64+0x3b/0x90 [ 240.215442] entrySYSCALL64afterhwframe+0x63/0xcd [ 240.215811] RIP: 0033:0x7f233b4e948a [ 240.216104] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 240.217615] RSP: 002b:00007fff02211ec8 EFLAGS: 00000202 ORIGRAX: 00000000000000a5 [ 240.218718] RAX: ffffffffffffffda RBX: 0000561cdc35b060 RCX: 00007f233b4e948a [ 240.219556] RDX: 0000561cdc35b260 RSI: 0000561cdc35b2e0 RDI: 0000561cdc363af0 [ 240.219975] RBP: 0000000000000000 R08: 0000561cdc35b280 R09: 0000000000000020 [ 240.220403] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000561cdc363af0 [ 240.220803] R13: 000 ---truncated---

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

fs/ntfs3: Validate BOOT recordsize

When the NTFS BOOT recordsize field < 0, it represents a shift value. However, there is no sanity check on the shift result and the sbi->recordbits calculation through blksizebits() assumes the size always > 256, which could lead to NPD while mounting a malformed NTFS image.

[ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 318.675682] #PF: supervisor read access in kernel mode [ 318.675869] #PF: errorcode(0x0000) - not-present page [ 318.676246] PGD 0 P4D 0 [ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5 [ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 318.678136] RIP: 0010:nifindattr+0x2d/0x1c0 [ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0 [ 318.685623] Call Trace: [ 318.686607] <TASK> [ 318.686872] ? ntfsallocinode+0x1a/0x60 [ 318.687235] attrloadrunsvcn+0x2b/0xa0 [ 318.687468] miread+0xbb/0x250 [ 318.687576] ntfsiget5+0x114/0xd90 [ 318.687750] ntfsfillsuper+0x588/0x11b0 [ 318.687953] ? putntfs+0x130/0x130 [ 318.688065] ? snprintf+0x49/0x70 [ 318.688164] ? putntfs+0x130/0x130 [ 318.688256] gettreebdev+0x16a/0x260 [ 318.688407] vfsgettree+0x20/0xb0 [ 318.688519] pathmount+0x2dc/0x9b0 [ 318.688877] domount+0x74/0x90 [ 318.689142] x64sysmount+0x89/0xd0 [ 318.689636] dosyscall64+0x3b/0x90 [ 318.689998] entrySYSCALL64afterhwframe+0x63/0xcd [ 318.690318] RIP: 0033:0x7fd9e133c48a [ 318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIGRAX: 00000000000000a5 [ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a [ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0 [ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020 [ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0 [ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff [ 318.693007] </TASK> [ 318.693271] Modules linked in: [ 318.693614] CR2: 0000000000000158 [ 318.694446] ---[ end trace 0000000000000000 ]--- [ 318.694779] RIP: 0010:nifindattr+0x2d/0x1c0 [ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ ---truncated---