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

NFSD: Fix potential use-after-free in nfsdfileput()

nfsdfileputnoref() can free @nf, so don't dereference @nf immediately upon return from nfsdfileputnoref().

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

netfilter: conntrack: re-fetch conntrack after insertion

In case the conntrack is clashing, insertion can free skb->nfct and set skb->nfct to the already-confirmed entry.

This wasn't found before because the conntrack entry and the extension space used to free'd after an rcu grace period, plus the race needs events enabled to trigger.

btrfs: fix a race between renames and directory logging

Arm guests can cause Dom0 DoS via PV devices When mapping pages of guests on Arm, dom0 is using an rbtree to keep track of the foreign mappings. Updating of that rbtree is not always done completely with the related lock held, resulting in a small race window, which can be used by unprivileged guests via PV devices to cause inconsistencies of the rbtree. These inconsistencies can lead to Denial of Service (DoS) of dom0, e.g. by causing crashes or the inability to perform further mappings of other guests' memory pages.

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

mt76: fix use-after-free by removing a non-RCU wcid pointer

Fixes an issue caught by KASAN about use-after-free in mt76txqschedule by protecting mtxq->wcid with rculock between mt76txqschedule and stainfo[alloc, free].

[18853.876689] ================================================================== [18853.876751] BUG: KASAN: use-after-free in mt76txqschedule+0x204/0xaf8 [mt76] [18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883 [18853.876786] [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215

[18853.876840] Call trace: [18853.876861] dumpbacktrace+0x0/0x3ec [18853.876878] showstack+0x20/0x2c [18853.876899] dumpstack+0x11c/0x1ac [18853.876918] printaddressdescription+0x74/0x514 [18853.876934] kasanreport+0x134/0x174 [18853.876948] asanreportload8noabort+0x44/0x50 [18853.876976] mt76txqschedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877002] mt76txqscheduleall+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877030] mt7921txworker+0xa0/0x1cc [mt7921common f0875ebac9d7b4754e1010549e7db50fbd90a047] [18853.877054] mt76workerfn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877071] kthread+0x2f8/0x3b8 [18853.877087] retfromfork+0x10/0x30 [18853.877098] [18853.877112] Allocated by task 941: [18853.877131] kasansavestack+0x38/0x68 [18853.877147] kasankmalloc+0xd4/0xfc [18853.877163] kasankmalloc+0x10/0x1c [18853.877177] kmalloc+0x264/0x3c4 [18853.877294] stainfoalloc+0x460/0xf88 [mac80211] [18853.877410] ieee80211prepconnection+0x204/0x1ee0 [mac80211] [18853.877523] ieee80211mgdauth+0x6c4/0xa4c [mac80211] [18853.877635] ieee80211auth+0x20/0x2c [mac80211] [18853.877733] rdevauth+0x7c/0x438 [cfg80211] [18853.877826] cfg80211mlmeauth+0x26c/0x390 [cfg80211] [18853.877919] nl80211authenticate+0x6d4/0x904 [cfg80211] [18853.877938] genlrcvmsg+0x748/0x93c [18853.877954] netlinkrcvskb+0x160/0x2a8 [18853.877969] genlrcv+0x3c/0x54 [18853.877985] netlinkunicastkernel+0x104/0x1ec [18853.877999] netlinkunicast+0x178/0x268 [18853.878015] netlinksendmsg+0x3cc/0x5f0 [18853.878030] socksendmsg+0xb4/0xd8 [18853.878043] syssendmsg+0x2f8/0x53c [18853.878058] syssendmsg+0xe8/0x150 [18853.878071] syssendmsg+0xc4/0x1f4 [18853.878087] arm64compatsyssendmsg+0x88/0x9c [18853.878101] el0svccommon+0x1b4/0x390 [18853.878115] doel0svccompat+0x8c/0xdc [18853.878131] el0svccompat+0x10/0x1c [18853.878146] el0synccompathandler+0xa8/0xcc [18853.878161] el0synccompat+0x188/0x1c0 [18853.878171] [18853.878183] Freed by task 10927: [18853.878200] kasansavestack+0x38/0x68 [18853.878215] kasansettrack+0x28/0x3c [18853.878228] kasansetfreeinfo+0x24/0x48 [18853.878244] kasanslabfree+0x11c/0x154 [18853.878259] kasanslabfree+0x14/0x24 [18853.878273] slabfreefreelisthook+0xac/0x1b0 [18853.878287] kfree+0x104/0x390 [18853.878402] stainfofree+0x198/0x210 [mac80211] [18853.878515] stainfodestroypart2+0x230/0x2d4 [mac80211] [18853.878628] stainfoflush+0x300/0x37c [mac80211] [18853.878740] ieee80211setdisassoc+0x2cc/0xa7c [mac80211] [18853.878851] ieee80211mgddeauth+0x4a4/0x10a0 [mac80211] [18853.878962] ieee80211deauth+0x20/0x2c [mac80211] [18853.879057] rdevdeauth+0x7c/0x438 [cfg80211] [18853.879150] cfg80211mlmedeauth+0x274/0x414 [cfg80211] [18853.879243] cfg80211mlmedown+0xe4/0x118 [cfg80211] [18853.879335] cfg80211disconnect+0x218/0x2d8 [cfg80211] [18853.879427] cfg80211leave+0x17c/0x240 [cfg80211] [18853.879519] cfg80211leave+0x3c/0x58 [cfg80211] [18853.879611] wiphysuspend+0xdc/0x200 [cfg80211] [18853.879628] dpmruncallback+0x58/0x408 [18853.879642] devicesuspend+0x4cc/0x864 [18853.879658] asyncsuspend+0x34/0xf4 [18 ---truncated---

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

rtw89: cfo: check macid to avoid out-of-bounds

Somehow, hardware reports incorrect macid and pollute memory. Check index before we access the array.

UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89pc Tainted: G OE Call Trace: <IRQ> showstack+0x52/0x58 dumpstacklvl+0x4c/0x63 dumpstack+0x10/0x12 ubsanepilogue+0x9/0x45 ubsanhandleoutofbounds.cold+0x44/0x49 ? allocskb+0x92/0x1d0 rtw89phycfoparse+0x44/0x7f [rtw89core] rtw89corerx+0x261/0x871 [rtw89core] ? allocskb+0xee/0x1d0 rtw89pcinapipoll+0x3fa/0x4ea [rtw89pci] napipoll+0x33/0x1a0 netrxaction+0x126/0x260 ? queuework+0x217/0x4c0 dosoftirq+0xd9/0x315 ? disableirqnosync+0x10/0x10 dosoftirq.part.0+0x6d/0x90 </IRQ> <TASK> localbhenableip+0x62/0x70 rtw89pciinterruptthreadfn+0x182/0x1a6 [rtw89pci] irqthreadfn+0x28/0x60 irqthread+0xc8/0x190 ? irqthreadfn+0x60/0x60 kthread+0x16b/0x190 ? irqthreadcheckaffinity+0xe0/0xe0 ? setkthreadstruct+0x50/0x50 retfromfork+0x22/0x30 </TASK>

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

mt76: fix tx status related use-after-free race on station removal

There is a small race window where ongoing tx activity can lead to a skb getting added to the status tracking idr after that idr has already been cleaned up, which will keep the wcid linked in the status poll list. Fix this by only adding status skbs if the wcid pointer is still assigned in dev->wcid, which gets cleared early by mt76staprercuremove

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

wl1251: dynamically allocate memory used for DMA

With introduction of vmap'ed stacks, stack parameters can no longer be used for DMA and now leads to kernel panic.

It happens at several places for the wl1251 (e.g. when accessed through SDIO) making it unuseable on e.g. the OpenPandora.

We solve this by allocating temporary buffers or use wl1251read32().

Tested on v5.18-rc5 with OpenPandora.

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

wifi: wcn36xx: fix channel survey memory allocation size

KASAN reported a memory allocation issue in wcn->chansurvey due to incorrect size calculation. This commit uses kcalloc to allocate memory for wcn->chansurvey, ensuring proper initialization and preventing the use of uninitialized values when there are no frames on the channel.

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

hisiaccvfiopci: bugfix live migration function without VF device driver

If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors.

Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed.

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

SUNRPC: Trap RDMA segment overflows

Prevent svcrdmabuildwrites() from walking off the end of a Write chunk's segment array. Caught with KASAN.

The test that this fix replaces is invalid, and might have been left over from an earlier prototype of the PCL work.

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

ax25: Fix refcount imbalance on inbound connections

When releasing a socket in ax25release(), we call netdevput() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdevhold(). This imbalance leads to refcount errors, and ultimately to kernel crashes.

A typical call trace for the above situation will start with one of the following errors:

refcountt: decrement hit 0; leaking memory. refcountt: underflow; use-after-free.

And will then have a trace like:

Call Trace: <TASK> ? showregs+0x64/0x70 ? warn+0x83/0x120 ? refcountwarnsaturate+0xb2/0x100 ? reportbug+0x158/0x190 ? prbreadvalid+0x20/0x30 ? handlebug+0x3e/0x70 ? excinvalidop+0x1c/0x70 ? asmexcinvalidop+0x1f/0x30 ? refcountwarnsaturate+0xb2/0x100 ? refcountwarnsaturate+0xb2/0x100 ax25release+0x2ad/0x360 sockrelease+0x35/0xa0 sockclose+0x19/0x20 [...]

On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop:

unregisternetdevice: waiting for ax0 to become free. Usage count = 0

This patch corrects these issues by ensuring that we call netdevhold() and ax25devhold() for new connections in ax25accept(). This makes the logic leading to ax25accept() match the logic for ax25bind(): in both cases we increment the refcount, which is ultimately decremented in ax25release().

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

netfilter: nftables: double hook unregistration in netns path

nftreleasehooks() is called from prenetns exit path which unregisters the hooks, then the NETDEVUNREGISTER event is triggered which unregisters the hooks again.

[ 565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 nfunregisternethook+0x247/0x270 [...] [ 565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G E 5.18.0-rc7+ #27 [ 565.253682] Workqueue: netns cleanupnet [ 565.257059] RIP: 0010:nfunregisternethook+0x247/0x270 [...] [ 565.297120] Call Trace: [ 565.300900] <TASK> [ 565.304683] nftablesflowtableevent+0x16a/0x220 [nftables] [ 565.308518] rawnotifiercallchain+0x63/0x80 [ 565.312386] unregisternetdevicemany+0x54f/0xb50

Unregister and destroy netdev hook from netns preexit via kfreercu so the NETDEVUNREGISTER path see unregistered hooks.

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

An issue was discovered in the Linux kernel through 5.18.3 on powerpc 32-bit platforms. There is a buffer overflow in ptrace PEEKUSER and POKEUSER (aka PEEKUSR and POKEUSR) when accessing floating point registers.

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

virtionet: Add hashkeylength check

Add hashkeylength check in virtnetprobe() to avoid possible out of bound errors when setting/reading the hash key.

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

firmware: armscmi: Fix list protocols enumeration in the base protocol

While enumerating protocols implemented by the SCMI platform using BASEDISCOVERLISTPROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loopnumret' is big enough.

Fix the validation avoiding the addition.

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

bpf, testrun: Subtract size of xdpframe from allowed metadata size

The xdpframe structure takes up part of the XDP frame headroom, limiting the size of the metadata. However, in bpftestrun, we don't take this into account, which makes it possible for userspace to supply a metadata size that is too large (taking up the entire headroom).

If userspace supplies such a large metadata size in live packet mode, the xdpupdateframefrombuff() call in xdptestruninitpage() call will fail, after which packet transmission proceeds with an uninitialised frame structure, leading to the usual Bad Stuff.

The commit in the Fixes tag fixed a related bug where the second check in xdpupdateframefrombuff() could fail, but did not add any additional constraints on the metadata size. Complete the fix by adding an additional check on the metadata size. Reorder the checks slightly to make the logic clearer and add a comment.

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

rpmsg: char: Fix use-after-free on probe error path

rpmsgchrdevprobe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsgchrdeveptdevadd(). If rpmsgchrdeveptdevadd() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer.

Avoid publishing eptdev through the default endpoint until rpmsgchrdeveptdevadd() succeeds. Messages received before the priv pointer is published should be ignored by rpmsgeptcb(). Flow-control updates can hit rpmsgeptflowcb() in the same window, so make both callbacks return success when priv is NULL.

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

mm: hugememory: don't force huge page alignment on 32 bit

commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") caused two issues [1] [2] reported on 32 bit system or compat userspace.

It doesn't make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space.

[1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/

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

tcp: add accessors to read/set tp->sndcwnd

We had various bugs over the years with code breaking the assumption that tp->sndcwnd is greater than zero.

Lately, syzbot reported the WARNONONCE(!tp->priorcwnd) added in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcpcwndreduction") can trigger, and without a repro we would have to spend considerable time finding the bug.

Instead of complaining too late, we want to catch where and when tp->sndcwnd is set to an illegal value.

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

tcp: fix tcpmtupprobesuccess vs wrong sndcwnd

syzbot got a new report [1] finally pointing to a very old bug, added in initial support for MTU probing.

tcpmtuprobe() has checks about starting an MTU probe if tcpsndcwnd(tp) >= 11.

But nothing prevents tcpsndcwnd(tp) to be reduced later and before the MTU probe succeeds.

This bug would lead to potential zero-divides.

Debugging added in commit 40570375356c ("tcp: add accessors to read/set tp->sndcwnd") has paid off :)

While we are at it, address potential overflows in this code.

[1] WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcpmtupprobesuccess+0x366/0x570 net/ipv4/tcpinput.c:2712 Modules linked in: CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tcpsndcwndset include/net/tcp.h:1219 [inline] RIP: 0010:tcpmtupprobesuccess+0x366/0x570 net/ipv4/tcpinput.c:2712 Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287 RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000 RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520 R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50 R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000 FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tcpcleanrtxqueue+0x223a/0x2da0 net/ipv4/tcpinput.c:3356 tcpack+0x1962/0x3c90 net/ipv4/tcpinput.c:3861 tcprcvestablished+0x7c8/0x1ac0 net/ipv4/tcpinput.c:5973 tcpv6dorcv+0x57b/0x1210 net/ipv6/tcpipv6.c:1476 skbacklogrcv include/net/sock.h:1061 [inline] releasesock+0x1d8/0x4c0 net/core/sock.c:2849 releasesock+0x5d/0x1c0 net/core/sock.c:3404 skstreamwaitmemory+0x700/0xdc0 net/core/stream.c:145 tcpsendmsglocked+0x111d/0x3fc0 net/ipv4/tcp.c:1410 tcpsendmsg+0x2c/0x40 net/ipv4/tcp.c:1448 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline] syssendto+0x439/0x5c0 net/socket.c:2119 dosyssendto net/socket.c:2131 [inline] sesyssendto net/socket.c:2127 [inline] x64syssendto+0xda/0xf0 net/socket.c:2127 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x46/0xb0 RIP: 0033:0x7f6431289109 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIGRAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109 RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000

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

nvmet: move async event work off nvmet-wq

For target nvmetctrlfree() flushes ctrl->asynceventwork. If nvmetctrlfree() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-

A. Async event work queued on nvmet-wq (prior to disconnect): nvmetexecuteasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)

nvmetaddasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)

B. Full pre-work chain (RDMA CM path): nvmetrdmacmhandler() nvmetrdmaqueuedisconnect() nvmetrdmaqueuedisconnect() queuework(nvmetwq, &queue->releasework) processonework() lock((wqcompletion)nvmet-wq) <--------- 1st nvmetrdmareleasequeuework()

C. Recursive path (same worker): nvmetrdmareleasequeuework() nvmetrdmafreequeue() nvmetsqdestroy() nvmetctrlput() nvmetctrlfree() flushwork(&ctrl->asynceventwork) flushwork() touchwqlockdepmap() lock((wqcompletion)nvmet-wq) <--------- 2nd

Lockdep splat:

============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N -------------------------------------------- kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: touchwqlockdepmap+0x26/0x90

but task is already holding lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660

3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660 #1: ffffc9000e6cbe28 ((workcompletion)(&queue->releasework)){+.+.}-{0:0}, at: processonework+0x1c5/0x660 #2: ffffffff82d4db60 (rcureadlock){....}-{1:3}, at: flushwork+0x62/0x530

Workqueue: nvmet-wq nvmetrdmareleasequeuework [nvmetrdma] Call Trace: flushwork+0x268/0x530 nvmetctrlfree+0x140/0x310 [nvmet] nvmetcqput+0x74/0x90 [nvmet] nvmetrdmafreequeue+0x23/0xe0 [nvmetrdma] nvmetrdmareleasequeuework+0x19/0x50 [nvmetrdma] processonework+0x206/0x660 workerthread+0x184/0x320 kthread+0x10c/0x240 retfromfork+0x319/0x390

Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.

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

net: bonding: Fix ndtbl NULL dereference when IPv6 is disabled

When booting with the 'ipv6.disable=1' parameter, the ndtbl is never initialized because inet6init() exits before ndiscinit() is called which initializes it. If bonding ARP/NS validation is enabled, an IPv6 NS/NA packet received on a slave can reach bondvalidatena(), which calls bondhasthisip6(). That path calls ipv6chkaddr() and can crash in ipv6chkaddrandflags().

BUG: kernel NULL pointer dereference, address: 00000000000005d8 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ipv6chkaddrandflags+0x69/0x170 Call Trace: <IRQ> ipv6chkaddr+0x1f/0x30 bondvalidatena+0x12e/0x1d0 [bonding] ? pfxbondhandleframe+0x10/0x10 [bonding] bondrcvvalidate+0x1a0/0x450 [bonding] bondhandleframe+0x5e/0x290 [bonding] ? srsoaliasreturnthunk+0x5/0xfbef5 netifreceiveskbcore.constprop.0+0x3e8/0xe50 ? srsoaliasreturnthunk+0x5/0xfbef5 ? updatecfsrqloadavg+0x1a/0x240 ? srsoaliasreturnthunk+0x5/0xfbef5 ? enqueueentity+0x5e/0x240 netifreceiveskbonecore+0x39/0xa0 processbacklog+0x9c/0x150 napipoll+0x30/0x200 ? srsoaliasreturnthunk+0x5/0xfbef5 netrxaction+0x338/0x3b0 handlesoftirqs+0xc9/0x2a0 dosoftirq+0x42/0x60 </IRQ> <TASK> localbhenableip+0x62/0x70 devqueuexmit+0x2d3/0x1000 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? packetparseheaders+0x10a/0x1a0 packetsendmsg+0x10da/0x1700 ? kickpool+0x5f/0x140 ? srsoaliasreturnthunk+0x5/0xfbef5 ? queuework+0x12d/0x4f0 syssendto+0x1f3/0x220 x64syssendto+0x24/0x30 dosyscall64+0x101/0xf80 ? excpagefault+0x6e/0x170 ? srsoaliasreturnthunk+0x5/0xfbef5 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Fix this by checking ipv6modenabled() before dispatching IPv6 packets to bondnarcv(). If IPv6 is disabled, return early from bondrcvvalidate() and avoid the path to ipv6chkaddr().

A flaw memory leak in the Linux Kernel XDP (eXpress Data Path) was found. It can lead to denial of service for some specific configurations like if the non root privileged user from the host system can send malicious packets to the guest systems. This flaw actual for the Linux Kernel versions 5.9 - 5.18.

References: https://www.openwall.com/lists/oss-security/2022/07/05/5 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/xen-netfront.c?h=v5.19-rc7&id=f63c2c2032c2e3caad9add3b82cc6e91c376fd26

Last updated 24 July 2024

A use-after-free flaw was found in the Linux kernel MCTP (Management Component Transport Protocol) functionality. This issue occurs when a user simultaneously calls DROPTAG ioctl and socket close happens, which could allow a local user to crash the system or potentially escalate their privileges on the system.

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

crypto: virtio/akcipher - Fix stack overflow on memcpy

sizeof(struct virtiocryptoakciphersessionpara) is less than sizeof(struct virtiocryptoopctrlreq::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtiocryptoakcipheralgs.o

crypto: arm64/neonbs - fix out-of-bounds access on short input

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

usb: ulpi: Fix debugfs directory leak

The Linux kernel CVE team has assigned CVE-2024-26919 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041738-CVE-2024-26919-5100@gregkh/T