OESA-2024-2491

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Fix NULL sring after live migration A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busypoll/busyread enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennetpoll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finishtaskswitch+0x71/0x230 timerqueuedel+0x1d/0x40 hrtimertrytocancel+0xb5/0x110 xennetallocrxbuffers+0x2a0/0x2a0 napibusyloop+0xdb/0x270 sockpoll+0x87/0x90 dosyspoll+0x26f/0x580 tracingmapinsert+0x1d4/0x2f0 eventhisttrigger+0x14a/0x260 finishtaskswitch+0x71/0x230 _schedule+0x256/0x890 recalcsigpending+0x1b/0x50 xenschedclock+0x15/0x20 _rbreservenext+0x12d/0x140 ringbufferlockreserve+0x123/0x3d0 eventtriggerscall+0x87/0xb0 traceeventbuffercommit+0x1c4/0x210 xenclocksourcegetcycles+0x15/0x20 ktimegetts64+0x51/0xf0 SySppoll+0x160/0x1a0 SySppoll+0x160/0x1a0 dosyscall64+0x73/0x130 entrySYSCALL64afterhwframe+0x41/0xa6 ... RIP: xennetpoll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time(CVE-2022-48969)

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

bonding: stop the device in bondsetupby_slave()

Commit 9eed321cde22 ("net: lapbether: only support ethernet devices") has been able to keep syzbot away from net/lapb, until today.

In the following splat [1], the issue is that a lapbether device has been created on a bonding device without members. Then adding a non ARPHRD_ETHER member forced the bonding master to change its type.

The fix is to make sure we call devclose() in bondsetupbyslave() so that the potential linked lapbether devices (or any other devices having assumptions on the physical device) are removed.

A similar bug has been addressed in commit 40baec225765 ("bonding: fix panic on non-ARPHRD_ETHER enslave failure")

[1] skbuff: skbunderpanic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0 kernel BUG at net/core/skbuff.c:192 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skbpanic net/core/skbuff.c:188 [inline] pc : skbunderpanic+0x13c/0x140 net/core/skbuff.c:202 lr : skbpanic net/core/skbuff.c:188 [inline] lr : skbunderpanic+0x13c/0x140 net/core/skbuff.c:202 sp : ffff800096a06aa0 x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000 x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140 x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100 x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001 x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00 x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086 Call trace: skbpanic net/core/skbuff.c:188 [inline] skbunderpanic+0x13c/0x140 net/core/skbuff.c:202 skbpush+0xf0/0x108 net/core/skbuff.c:2446 ip6greheader+0xbc/0x738 net/ipv6/ip6gre.c:1384 devhardheader include/linux/netdevice.h:3136 [inline] lapbethdatatransmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapbdatatransmit+0x8c/0xb0 net/lapb/lapbiface.c:447 lapbtransmitbuffer+0x178/0x204 net/lapb/lapbout.c:149 lapbsendcontrol+0x220/0x320 net/lapb/lapbsubr.c:251 _lapbdisconnectrequest+0x9c/0x17c net/lapb/lapbiface.c:326 lapbdeviceevent+0x288/0x4e0 net/lapb/lapbiface.c:492 notifiercallchain+0x1a4/0x510 kernel/notifier.c:93 rawnotifiercallchain+0x3c/0x50 kernel/notifier.c:461 callnetdevicenotifiersinfo net/core/dev.c:1970 [inline] callnetdevicenotifiersextack net/core/dev.c:2008 [inline] callnetdevicenotifiers net/core/dev.c:2022 [inline] _devclosemany+0x1b8/0x3c4 net/core/dev.c:1508 devclosemany+0x1e0/0x470 net/core/dev.c:1559 devclose+0x174/0x250 net/core/dev.c:1585 lapbethdeviceevent+0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifiercallchain+0x1a4/0x510 kernel/notifier.c:93 rawnotifiercallchain+0x3c/0x50 kernel/notifier.c:461 callnetdevicenotifiersinfo net/core/dev.c:1970 [inline] callnetdevicenotifiersextack net/core/dev.c:2008 [inline] callnetdevicenotifiers net/core/dev.c:2022 [inline] _devclosemany+0x1b8/0x3c4 net/core/dev.c:1508 devclosemany+0x1e0/0x470 net/core/dev.c:1559 devclose+0x174/0x250 net/core/dev.c:1585 bondenslave+0x2298/0x30cc drivers/net/bonding/bondmain.c:2332 bonddoioctl+0x268/0xc64 drivers/net/bonding/bondmain.c:4539 devifsioc+0x754/0x9ac devioctl+0x4d8/0xd34 net/core/devioctl.c:786 sockdoioctl+0x1d4/0x2d0 net/socket.c:1217 sockioctl+0x4e8/0x834 net/socket.c:1322 vfsioctl fs/ioctl.c:51 [inline] _do ---truncated---(CVE-2023-52784)

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

llc: verify mac len before reading mac header

LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header.

Syzbot was able to enter llcrcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tunpi header when not configuring IFFNOPI).

BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
__netif_receive_skb_one_core net/core/dev.c:5523 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
netif_receive_skb_internal net/core/dev.c:5723 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5782
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002

Add a maclen test before all three ethhdr(skb) calls under net/llc.

There are further uses in include/net/llcpdu.h. All these are protected by a test skb->protocol == ETHP8022. Which does not protect against this tun scenario.

But the maclen test added in this patch in llcfixupskb will indirectly protect those too. That is called from llcrcv before any other LLC code.

It is tempting to just add a blanket maclen check in llcrcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring.

At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this.(CVE-2023-52843)

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

SUNRPC: Fix UAF in svctcplistendataready()

After the listener svcsock is freed, and before invoking svctcpaccept() for the established child sock, there is a window that the newsock retaining a freed listener svcsock in skuserdata which cloning from parent. In the race window, if data is received on the newsock, we will observe use-after-free report in svctcplistendataready().

Reproduce by two tasks:

1. while :; do rpc.nfsd 0 ; rpc.nfsd; done
2. while :; do echo "" | ncat -4 127.0.0.1 2049 ; done

KASAN report:

================================================================== BUG: KASAN: slab-use-after-free in svctcplistendataready+0x1cf/0x1f0 [sunrpc] Read of size 8 at addr ffff888139d96228 by task nc/102553 CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <IRQ> dumpstacklvl+0x33/0x50 printaddressdescription.constprop.0+0x27/0x310 printreport+0x3e/0x70 kasanreport+0xae/0xe0 svctcplistendataready+0x1cf/0x1f0 [sunrpc] tcpdataqueue+0x9f4/0x20e0 tcprcvestablished+0x666/0x1f60 tcpv4dorcv+0x51c/0x850 tcpv4rcv+0x23fc/0x2e80 ipprotocoldeliverrcu+0x62/0x300 iplocaldeliverfinish+0x267/0x350 iplocaldeliver+0x18b/0x2d0 iprcv+0x2fb/0x370 _netifreceiveskbonecore+0x166/0x1b0 processbacklog+0x24c/0x5e0 _napipoll+0xa2/0x500 netrxaction+0x854/0xc90 _dosoftirq+0x1bb/0x5de do_softirq+0xcb/0x100 </IRQ> <TASK> ... </TASK>

Allocated by task 102371: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 _kasankmalloc+0x7b/0x90 svcsetupsocket+0x52/0x4f0 [sunrpc] svcaddsock+0x20d/0x400 [sunrpc] _writeportsaddfd+0x209/0x390 [nfsd] writeports+0x239/0x2c0 [nfsd] nfsctltransactionwrite+0xac/0x110 [nfsd] vfswrite+0x1c3/0xae0 ksyswrite+0xed/0x1c0 dosyscall64+0x38/0x90 entrySYSCALL64after_hwframe+0x72/0xdc

Freed by task 102551: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x50 _kasanslabfree+0x106/0x190 _kmemcachefree+0x133/0x270 svcxprtfree+0x1e2/0x350 [sunrpc] svcxprtdestroyall+0x25a/0x440 [sunrpc] nfsdput+0x125/0x240 [nfsd] nfsdsvc+0x2cb/0x3c0 [nfsd] writethreads+0x1ac/0x2a0 [nfsd] nfsctltransactionwrite+0xac/0x110 [nfsd] vfswrite+0x1c3/0xae0 ksyswrite+0xed/0x1c0 dosyscall64+0x38/0x90 entrySYSCALL64after_hwframe+0x72/0xdc

Fix the UAF by simply doing nothing in svctcplistendataready() if state != TCP_LISTEN, that will avoid dereferencing svsk for all child socket.(CVE-2023-52885)

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

perf/aux: Fix AUX buffer serialization

Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it.

Note that in the lock order comment the perfevent::mmapmutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch.(CVE-2024-46713)

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spinunlockirqrestore() called with IRQs enabled Fix missuse of spinlockirq()/spinunlockirq() when spinlockirqsave()/spinlockirqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: rawlocalirqrestore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warnbogusirqrestore+0x30/0x40 ... Call trace: warnbogusirqrestore+0x30/0x40 _rawspinunlockirqrestore+0x84/0xc8 addqptolist+0x11c/0x148 [hnsrocehwv2] hnsrocecreateqpcommon.constprop.0+0x240/0x780 [hnsrocehwv2] hnsrocecreateqp+0x98/0x160 [hnsrocehwv2] createqp+0x138/0x258 ibcreateqpkernel+0x50/0xe8 createmadqp+0xa8/0x128 ibmadportopen+0x218/0x448 ibmadinitdevice+0x70/0x1f8 addclientcontext+0xfc/0x220 enabledeviceandget+0xd0/0x140 ibregisterdevice.part.0+0xf4/0x1c8 ibregisterdevice+0x34/0x50 hnsroceregisterdevice+0x174/0x3d0 [hnsrocehwv2] hnsroceinit+0xfc/0x2c0 [hnsrocehwv2] _hnsrocehwv2initinstance+0x7c/0x1d0 [hnsrocehwv2] hnsrocehwv2initinstance+0x9c/0x180 hnsrocehwv2

In the Linux kernel, the following vulnerability has been resolved: mm: call the securitymmapfile() LSM hook in remapfilepages() The remapfilepages syscall handler calls dommap() directly, which doesn't contain the LSM security check. And if the process has called personality(READIMPLIESEXEC) before and remapfilepages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by securitymmapfile LSM hook in the remapfilepages syscall handler before dommap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { sizet pagesz = sysconf(SCPAGESIZE); int mfd = syscall(SYSmemfdcreate, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROTREAD | PROTWRITE, MAPSHARED, mfd, 0); unsigned int old = syscall(SYSpersonality, 0xffffffff); syscall(SYSpersonality, READIMPLIESEXEC | old); syscall(SYSremapfilepages, buf, pagesz, 0, 2, 0); syscall(SYSpersonality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", ORDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) PM: subject line tweaks

In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3probe function, a timer is initialized with a callback function ether3ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3ledoff ether3remove | freenetdev(dev); | putdevic | kfree(dev); | | ether3outw(priv(dev)->regs.config2 |= CFG2CTRLO, REGCONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)

In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookupatid The lookupatid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the act_establish() and act_open_rpl() functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDEBYZERO issues reported by Coverity.(CVE-2024-49899)

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwlmvmtxskbsta() and iwlmvmtxmpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwlmvmstafrommac80211, which is dereferencing the ieee80211sta pointer. If sta is NULL, iwlmvmstafrommac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.(CVE-2024-49929)

In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: prevent nfskbduplicated corruption syzbot found that nfdupipv4() or nfdupipv6() could write per-cpu variable nfskbduplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using thiscpuwrite() in preemptible [00000000] code: syz.4.282/6316 caller is nfdupipv4+0x651/0x8f0 net/ipv4/netfilter/nfdupipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 checkpreemptiondisabled+0x10e/0x120 lib/smpprocessorid.c:49 nfdupipv4+0x651/0x8f0 net/ipv4/netfilter/nfdupipv4.c:87 nftdupipv4eval+0x1db/0x300 net/ipv4/netfilter/nftdupipv4.c:30 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x4ad/0x1da0 net/netfilter/nftablescore.c:288 nftdochainipv4+0x202/0x320 net/netfilter/nftchainfilter.c:23 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xc3/0x220 net/netfilter/core.c:626 nfhook+0x2c4/0x450 include/linux/netfilter.h:269 NFHOOKCOND include/linux/netfilter.h:302 [inline] ipoutput+0x185/0x230 net/ipv4/ipoutput.c:433 iplocalout net/ipv4/ipoutput.c:129 [inline] ipsendskb+0x74/0x100 net/ipv4/ipoutput.c:1495 udpsendskb+0xacf/0x1650 net/ipv4/udp.c:981 udpsendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x1a6/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2597 _syssendmsg net/socket.c:2651 [inline] _syssendmmsg+0x3b2/0x740 net/socket.c:2737 _dosyssendmmsg net/socket.c:2766 [inline] _sesyssendmmsg net/socket.c:2763 [inline] _x64syssendmmsg+0xa0/0xb0 net/socket.c:2763 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIGRAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 </TASK>(CVE-2024-49952)

In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTOUNSPEC where needed syzbot managed to call xtcluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xtcluster.c:72 xtclustermt+0x196/0x780 [..] ebtdotable+0x174b/0x2a40 Module registers to NFPROTOUNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skbnetworkheader() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XTCONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBTCONTINUE is a completely different value than XTCONTINUE. Most matches/targets are changed to register for NFPROTOIPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.(CVE-2024-50038)

In the Linux kernel, the following vulnerability has been resolved: netfilter: brnetfilter: fix panic with metadatadst skb Fix a kernel panic in the brnetfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in brnfdevqueuexmit. It is dependent on: 1) the brnetfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, brhandleegressvlantunnel is called and changes the skbdst to the tunnel dst. The tunneldst is a metadata type of dst, i.e., skbvaliddst(skb) is false, and metadata->dst.dev is NULL. Then in the brnetfilter hooks, in brnfdevqueuexmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling brnfipfragment, which in turns call ipskbdstmtu. The ipdstmtu tries to use the skbdst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6udptunnel udptunnel veth brnetfilter bridge stp llc ipv6 crct10difce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : brnfdevqueuexmit+0x390/0x4ec [brnetfilter] [ 176.297382] lr : brnfdevqueuexmit+0x2ac/0x4ec [brnetfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] brnfdevqueuexmit+0x390/0x4ec [brnetfilter] [ 176.301411] brnfpostrouting+0x2a8/0x3e4 [brnetfilter] [ 176.301703] nfhookslow+0x48/0x124 [ 176.302060] brforwardfinish+0xc8/0xe8 [bridge] [ 176.302371] brnfhookthresh+0x124/0x134 [brnetfilter] [ 176.302605] brnfforwardfinish+0x118/0x22c [brnetfilter] [ 176.302824] brnfforwardip.part.0+0x264/0x290 [brnetfilter] [ 176.303136] brnfforward+0x2b8/0x4e0 [brnetfilter] [ 176.303359] nfhook_slow+0x48/0x124 [ 176.303 ---truncated---(CVE-2024-50045)

In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes connum of connections. After establishing all its connections, the information is exchanged between the client and server through the inforeq message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)

In the Linux kernel, the following vulnerability has been resolved: tty: ngsm: Fix use-after-free in gsmcleanupmux BUG: KASAN: slab-use-after-free in gsmcleanupmux+0x77b/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsmcleanupmux+0x77b/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] _pfxgsmcleanupmux+0x10/0x10 drivers/tty/ngsm.c:3124 [ngsm] _pfxschedclockcpu+0x10/0x10 kernel/sched/clock.c:389 updateloadavg+0x1c1/0x27b0 kernel/sched/fair.c:4500 _pfxminvruntimecbrotate+0x10/0x10 kernel/sched/fair.c:846 _rbinsertaugmented+0x492/0xbf0 lib/rbtree.c:161 gsmldioctl+0x395/0x1450 drivers/tty/ngsm.c:3408 [ngsm] rawspinlockirqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 _pfxgsmldioctl+0x10/0x10 drivers/tty/ngsm.c:3822 [ngsm] ktimeget+0x5e/0x140 kernel/time/timekeeping.c:195 ldsemdownread+0x94/0x4e0 arch/x86/include/asm/atomic6464.h:79 _pfxldsemdownread+0x10/0x10 drivers/tty/ttyldsem.c:338 _pfxdovfsioctl+0x10/0x10 fs/ioctl.c:805 ttyioctl+0x643/0x1100 drivers/tty/ttyio.c:2818 Allocated by task 65: gsmdataalloc.constprop.0+0x27/0x190 drivers/tty/ngsm.c:926 [ngsm] gsmsend+0x2c/0x580 drivers/tty/ngsm.c:819 [ngsm] gsm1receive+0x547/0xad0 drivers/tty/ngsm.c:3038 [ngsm] gsmldreceivebuf+0x176/0x280 drivers/tty/ngsm.c:3609 [ngsm] ttyldiscreceivebuf+0x101/0x1e0 drivers/tty/ttybuffer.c:391 ttyportdefaultreceivebuf+0x61/0xa0 drivers/tty/ttyport.c:39 flushtoldisc+0x1b0/0x750 drivers/tty/ttybuffer.c:445 processscheduledworks+0x2b0/0x10d0 kernel/workqueue.c:3229 workerthread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 retfromfork+0x2d/0x70 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsmcleanupmux+0x36c/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] gsmldioctl+0x395/0x1450 drivers/tty/ngsm.c:3408 [ngsm] ttyioctl+0x643/0x1100 drivers/tty/ttyio.c:2818 [Analysis] gsmmsg on the txctrllist or txdatalist of gsmmux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)

In the Linux kernel, the following vulnerability has been resolved: unicode: Don't special case ignorable code points We don't need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)

In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udfgetfileshortad Check for overflow when computing alen in udfcurrentaext to mitigate later uninit-value use in udfgetfileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)

(CVE-2024-50151)

In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)

In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)

In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmappcount, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmappcount common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfsfindentry() Syzbot reported that a task hang occurs in vcsopen() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfsfindentry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfsgetfolio() fails. If the filesystem images is corrupted, and the isize of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfscheckfolio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfsfindentry(). The current interface of nilfsfindentry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfsfindentry(), so fix it together.(CVE-2024-50202)

In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in applyconstrainttosize() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"), and it is difficult to show that any of the interval parameters will satisfy the sndintervaltest() condition with data from the amdtprate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that pagesymlink(), called by nilfssymlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->nssegctorsem, swriters percpurwsem (intwrite) and the fsreclaim pseudo lock. This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFPKERNEL via inodenohighmem(). This is not a problem for symlinks read from the backing device, because the _GFPFS flag is dropped after inodenohighmem() is called. However, when a new symlink is created with nilfssymlink(), the gfp flags remain overwritten to GFPKERNEL. Then, memory allocation called from pagesymlink() etc. triggers memory reclamation including the FS layer, which may call nilfsevictinode() or nilfsdirtyinode(). And these can cause a deadlock if they are called while nilfs->nssegctorsem is held: Fix this issue by dropping the _GFPFS flag from the page cache GFP flags of newly created symlinks in the same way that nilfsnewinode() and _nilfsreadinode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, _blockwritebeginint(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.(CVE-2024-50230)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Initialize struct nfsd4copy earlier Ensure the refcount and asynccopies fields are initialized early. cleanupasynccopy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in niclear() Checking of NTFSFLAGSLOGREPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)

In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mienumattr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.(CVE-2024-50248)

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in triegetnextkey() triegetnextkey() allocates a node stack with size trie->maxprefixlen, while it writes (trie->maxprefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with maxprefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to triegetnextkey with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2xaremove() Syzkaller is able to provoke null-ptr-dereference in ocfs2xaremove(): [ 57.319872] (a.out,1161,7):ocfs2xaremove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2xacleanupvaluetruncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2xablockwipenamevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? douseraddrfault+0x3e5/0x740 [ 57.333778] ? excpagefault+0x70/0x170 [ 57.334016] ? asmexcpagefault+0x2b/0x30 [ 57.334263] ? _pfxocfs2xablockwipenamevalue+0x10/0x10 [ 57.334596] ? ocfs2xablockwipenamevalue+0x2a/0xc0 [ 57.334913] ocfs2xaremoveentry+0x23/0xc0 [ 57.335164] ocfs2xaset+0x704/0xcf0 [ 57.335381] ? _rawspinunlock+0x1a/0x40 [ 57.335620] ? ocfs2inodecacheunlock+0x16/0x20 [ 57.335915] ? tracepreempton+0x1e/0x70 [ 57.336153] ? startthishandle+0x16c/0x500 [ 57.336410] ? preemptcountsub+0x50/0x80 [ 57.336656] ? rawreadunlock+0x20/0x40 [ 57.336906] ? startthishandle+0x16c/0x500 [ 57.337162] ocfs2xattrblockset+0xa6/0x1e0 [ 57.337424] _ocfs2xattrsethandle+0x1fd/0x5d0 [ 57.337706] ? ocfs2starttrans+0x13d/0x290 [ 57.337971] ocfs2xattrset+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2xattrtrustedset+0x28/0x30 [ 57.338665] ? ocfs2xattrtrustedset+0x28/0x30 [ 57.338948] _vfsremovexattr+0x92/0xc0 [ 57.339182] _vfsremovexattrlocked+0xd5/0x190 [ 57.339456] ? preemptcountsub+0x50/0x80 [ 57.339705] vfsremovexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2xaremove() -> ocfs2xavaluetruncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2xacleanupvaluetruncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2xaremoveentry(loc);' twice: * 1st: in ocfs2xacleanupvaluetruncate(); * 2nd: returning back to ocfs2xaremove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)

In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunximusbdriver // get the usb phy @glue->xceiv sunximusbprobe() -> devmusbgetphy(). 2) register and unregister platform driver @musbdriver musbprobe() -> sunximusbinit() use the phy here //the phy is released here musbremove() -> sunximusbexit() -> devmusbputphy() 3) register @musbdriver again musbprobe() -> sunximusbinit() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devmusbputphy() from sunximusbexit().(CVE-2024-50269)

In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insertdelayedref() if we need to update the action of an existing ref to BTRFSDROPDELAYEDREF, we delete the ref from its ref head's refaddlist using listdel(), which leaves the ref's addlist member not reinitialized, as listdel() sets the next and prev members of the list to LISTPOISON1 and LISTPOISON2, respectively. If later we end up calling dropdelayedref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at dropdelayedref() we call listempty() against the ref's addlist, which returns false since the list was not reinitialized after the listdel() and as a consequence we call listdel() again at dropdelayedref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIGLISTHARDENED and CONFIGDEBUGLIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with listdelinit() instead.(CVE-2024-50273)

In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: drivers/staging/media/av7110/av7110ca.c:270 dvbcaioctl() warn: potential spectre issue 'av7110->cislot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)

In the Linux kernel, the following vulnerability has been resolved: iouring/rw: fix missing NOWAIT check for ODIRECT start write When iouring starts a write, it'll call kiocbstartwrite() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But iouring unconditionally uses kiocbstartwrite(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: _switchto+0x1d8/0x348 _schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpurwsemwait+0x1e8/0x3f8 _percpudownread+0xe8/0x500 iowrite+0xbb8/0xff8 ioissuesqe+0x10c/0x1020 iosubmitsqes+0x614/0x2110 _arm64sysiouringenter+0x524/0x1038 invokesyscall+0x74/0x268 el0svccommon.constprop.0+0x160/0x238 doel0svc+0x44/0x60 el0svc+0x44/0xb0 el0t64synchandler+0x118/0x128 el0t64sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: _switchto+0x1d8/0x348 _schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpudownwrite+0x2b0/0x680 freezesuper+0x248/0x8a8 dovfsioctl+0x149c/0x1b18 _arm64sysioctl+0xd0/0x1a0 invokesyscall+0x74/0x268 el0svccommon.constprop.0+0x160/0x238 doel0svc+0x44/0x60 el0svc+0x44/0xb0 el0t64synchandler+0x118/0x128 el0t64sync+0x168/0x170 Fix this by having the iouring side honor IOCBNOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCBNOWAIT would always be set, this returns -EAGAIN which will have iouring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAPSYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.(CVE-2024-53052)

In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.(CVE-2024-53061)

In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decodegetfattrattrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BADPAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decodegetfattrattrs+0x2d6d/0x2f90 decodegetfattrattrs+0x2d6d/0x2f90 decodegetfattrgeneric+0x806/0xb00 nfs4xdrdecgetattr+0x1de/0x240 rpcauthunwraprespdecode+0xab/0x100 rpcauthunwrapresp+0x95/0xc0 calldecode+0x4ff/0xb50 _rpcexecute+0x57b/0x19d0 rpcexecute+0x368/0x5e0 rpcruntask+0xcfe/0xee0 nfs4procgetattr+0x5b5/0x990 _nfsrevalidateinode+0x477/0xd00 nfsaccessgetcached+0x1021/0x1cc0 nfsdoaccess+0x9f/0xae0 nfspermission+0x1e4/0x8c0 inodepermission+0x356/0x6c0 linkpathwalk+0x958/0x1330 pathlookupat+0xce/0x6b0 filenamelookup+0x23e/0x770 vfsstatx+0xe7/0x970 vfsfstatat+0x1f2/0x2c0 _sesysnewfstatat+0x67/0x880 _x64sysnewfstatat+0xbd/0x120 x64syscall+0x1826/0x3cf0 dosyscall64+0xd0/0x1b0 entrySYSCALL64afterhwframe+0x77/0x7f The KMSAN warning is triggered in decodegetfattrattrs(), when calling decodeattrmdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfsfattr_init().(CVE-2024-53066)