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

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

ksmbd: call rcubarrier() in ksmbdserverexit()

racy issue is triggered the bug by racing between closing a connection and rmmod. In ksmbd, rcubarrier() is not called at module unload time, so nothing prevents ksmbd from getting unloaded while it still has RCU callbacks pending. It leads to trigger unintended execution of kernel code locally and use to defeat protections such as Kernel Lockdown

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().

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---

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]

ALSA: hda/cs8409: Fix possible NULL dereference

bpf: Fail bpftimercancel when callback is being cancelled

fsdax: Fix infinite loop in daxiomaprw()

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().

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:

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

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

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

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

net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.

SIOCBRDELIF is passed to devioctl() first and later forwarded to brioctlcall(), which causes unnecessary RTNL dance and the splat below [0] under RTNL pressure.

Let's say Thread A is trying to detach a device from a bridge and Thread B is trying to remove the bridge.

In devioctl(), Thread A bumps the bridge device's refcnt by netdevhold() and releases RTNL because the following brioctlcall() also re-acquires RTNL.

In the race window, Thread B could acquire RTNL and try to remove the bridge device. Then, rtnlunlock() by Thread B will release RTNL and wait for netdevput() by Thread A.

Thread A, however, must hold RTNL after the unlock in devifsioc(), which may take long under RTNL pressure, resulting in the splat by Thread B.

Thread A (SIOCBRDELIF) Thread B (SIOCBRDELBR) ---------------------- ---------------------- sockioctl sockioctl - sockdoioctl - brioctlcall - devioctl - brioctlstub |- rtnllock | |- devifsioc ' ' |- dev = devgetbyname(...) |- netdevhold(dev, ...) . / |- rtnlunlock ------. | | |- brioctlcall ---> |- rtnllock Race | | - brioctlstub |- brdelbridge Window | | | |- dev = devgetbyname(...) | | | May take long | - brdevdelete(dev, ...) | | | under RTNL pressure | - unregisternetdevicequeue(dev, ...) | | | | - rtnlunlock \ | |- rtnllock <-' - netdevruntodo | |- ... - netdevruntodo | - rtnlunlock |- rtnlunlock | |- netdevwaitallrefsany |- netdevput(dev, ...) <----------------' Wait refcnt decrement and log splat below

To avoid blocking SIOCBRDELBR unnecessarily, let's not call devioctl() for SIOCBRADDIF and SIOCBRDELIF.

In the devioctl() path, we do the following:

1. Copy struct ifreq by getuserifreq in sockdoioctl() 2. Check CAPNETADMIN in devioctl() 3. Call devload() in devioctl() 4. Fetch the master dev from ifr.ifrname in devifsioc()

3. can be done by requestmodule() in brioctlcall(), so we move 1., 2., and 4. to brioctlstub().

Note that 2. is also checked later in adddelif(), but it's better performed before RTNL.

SIOCBRADDIF and SIOCBRDELIF have been processed in devioctl() since the pre-git era, and there seems to be no specific reason to process them there.

[0]: unregisternetdevice: waiting for wpan3 to become free. Usage count = 2 reftracker: wpan3@ffff8880662d8608 has 1/1 users at netdevtrackeralloc include/linux/netdevice.h:4282 [inline] netdevhold include/linux/netdevice.h:4311 [inline] devifsioc+0xc6a/0x1160 net/core/devioctl.c:624 devioctl+0x255/0x10c0 net/core/devioctl.c:826 sockdoioctl+0x1ca/0x260 net/socket.c:1213 sockioctl+0x23a/0x6c0 net/socket.c:1318 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl fs/ioctl.c:892 [inline] x64sysioctl+0x1a4/0x210 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcb/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

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

net: hns3: fix oops when unload drivers paralleling

When unload hclge driver, it tries to disable sriov first for each aedev node from hnae3aedevlist. If user unloads hns3 driver at the time, because it removes all the aedev nodes, and it may cause oops.

But we can't simply use hnae3commonlock for this. Because in the process flow of pcidisablesriov(), it will trigger the remove flow of VF, which will also take hnae3commonlock.

To fixes it, introduce a new mutex to protect the unload process.

fs/ntfs3: handle hdrfirstde() return value

afunix: Reject SIOCATMARK on non-stream sockets

bonding: check xdp prog when set bond mode

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:

afunix: Clear stale u->oobskb.

syzkaller started to report deadlock of unixgclock after commit 4090fa373f0e ("afunix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("afunix: Add OOB support").

The repro basically does the following.

from socket import from array import array

c1, c2 = socketpair(AFUNIX, SOCKSTREAM) c1.sendmsg([b'a'], [(SOLSOCKET, SCMRIGHTS, array("i", [c2.fileno()]))], MSGOOB) c2.recv(1) # blocked as no normal data in recv queue

c2.close() # done async and unblock recv() c1.close() # done async and trigger GC

A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close().

The problem here is wrong handling of OOB skb in manageoob(). When recvmsg() is called without MSGOOB, manageoob() is called to check if the peeked skb is OOB skb. In such a case, manageoob() pops it out of the receive queue but does not clear unixsock(sk)->oobskb. This is wrong in terms of uAPI.

Let's say we send "hello" with MSGOOB, and "world" without MSGOOB. The 'o' is handled as OOB data. When recv() is called twice without MSGOOB, the OOB data should be lost.

>>> from socket import >>> c1, c2 = socketpair(AFUNIX, SOCKSTREAM, 0) >>> c1.send(b'hello', MSGOOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSGOOB) # This should return an error b'o'

In the same situation, TCP actually returns -EINVAL for the last recv().

Also, if we do not clear unixsk(sk)->oobskb, unixpoll() always set EPOLLPRI even though the data has passed through by previous recv().

To avoid these issues, we must clear unixsk(sk)->oobskb when dequeuing it from recv queue.

The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop.

When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket.

With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue.

A flaw was found in the MCTP protocol in the Linux kernel. The function mctpunregister() reclaims the device's relevant resource when a netcard detaches. However, a running routine may be unaware of this and cause the use-after-free of the mdev->addrs object, potentially leading to a denial of service.

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:

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:

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:

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.