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

net/sched: schqfq: do not free existing class in qfqchangeclass()

Fixes qfqchangeclass() error case.

cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.

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

nvme-tcp: fix NULL pointer dereferences in nvmettcpbuildpduiovec

Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and dataoffset validation in nvmettcphandleh2cdatapdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2CDATA PDUs.

The nvmettcpbuildpduiovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2CDATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.

Attack vectors that trigger NULL pointer dereferences: 1. H2CDATA PDU sent before CONNECT → both pointers NULL 2. H2CDATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2CDATA PDU for uninitialized command slot → both pointers NULL

The fix validates both cmd->req.sg and cmd->iov before calling nvmettcpbuildpduiovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated

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

net: can: j1939: j1939xtprxrtssessionactive(): deactivate session upon receiving the second rts

Since j1939sessiondeactivateactivatenext() in j1939tprxtimer() is called only when the timer is enabled, we need to call j1939sessiondeactivateactivatenext() if we cancelled the timer. Otherwise, refcount for j1939session leaks, which will later appear as

| unregisternetdevice: waiting for vcan0 to become free. Usage count = 2.

problem.

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

libceph: return the handler error from monhandleauthdone()

Currently any error from cephauthhandlereplydone() is propagated via finishauth() but isn't returned from monhandleauthdone(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setupcrypto() and later lead to a NULL pointer dereference inside of prepareauthsignature().

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

libceph: make freechooseargmap() resilient to partial allocation

freechooseargmap() may dereference a NULL pointer if its caller fails after a partial allocation.

For example, in decodechooseargs(), if allocation of argmap->args fails, execution jumps to the fail label and freechooseargmap() is called. Since argmap->size is updated to a non-zero value before memory allocation, freechooseargmap() will iterate over argmap->args and dereference a NULL pointer.

To prevent this potential NULL pointer dereference and make freechooseargmap() more resilient, add checks for pointers before iterating.

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

libceph: replace overzealous BUGON in osdmapapplyincremental()

If the osdmap is (maliciously) corrupted such that the incremental osdmap epoch is different from what is expected, there is no need to BUG. Instead, just declare the incremental osdmap to be invalid.

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

nfsd: provide locking for v4endgrace

Writing to v4endgrace can race with server shutdown and result in memory being accessed after it was freed - reclaimstrhashtbl in particularly.

We cannot hold nfsdmutex across the nfsd4endgrace() call as that is held while clienttrackingop->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4endgrace, resulting in a deadlock.

nfsd4endgrace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4endgrace() might access.

However, we must be sure that writing to v4endgrace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->clientlock. It is set only while it is safe to make client tracking calls, and v4endgrace only schedules work while the flag is set with the spinlock held.

So this patch adds a nfsdnet field "clienttrackingactive" which is set as described. Another field "graceendforced", is set when v4endgrace is written. After this is set, and providing clienttrackingactive is set, the laundromat is scheduled. This "graceendforced" field bypasses other checks for whether the grace period has finished.

This resolves a race which can result in use-after-free.

HID: uclogic: Correct devm device reference for hidinput inputdev name

fs/ntfs3: Initialize allocated memory before use

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

team: Move team device type change at the end of teamportadd

Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device headerops.

In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that headerops->create of team0 is changed from ethheader to ipgreheader in the call to teamdevtypecheckchange.

Later when we end up in ipgreheader() struct iptunnel points to nonsense as the private data of the device still holds a struct team.

Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1

Move teamdevtypecheckchange down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail.

Also make sure to preserve the origial mtu assignment: - If portdev is not the same type as dev, dev takes mtu from portdev - If portdev is the same type as dev, portdev takes mtu from dev

This is done by adding a conditional before the call to devsetmtu to prevent it from assigning portdev->mtu = dev->mtu and instead letting teamdevtypecheckchange assign dev->mtu = portdev->mtu. The conditional is needed because the patch moves the call to teamdevtypecheckchange past devsetmtu.

Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot

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

tls: Use skdstget() and dstdevrcu() in getnetdevforsock().

getnetdevforsock() is called during setsockopt(), so not under RCU.

Using skdstget(sk)->dev could trigger UAF.

Let's use skdstget() and dstdevrcu().

Note that the only ->ndoskgetlowerdev() user is bondskgetlowerdev(), which uses RCU.

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

mm/ksm: fix flag-dropping behavior in ksmmadvise

syzkaller discovered the following crash: (kernel BUG)

[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUGPAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfdreleaseall+0x3a8/0x460

<snip other registers, drop unreliable trace>

[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfdrelease+0xef/0x1b0 [ 44.620976] fput+0x3f9/0xb60 [ 44.621240] fputclosesync+0x110/0x210 [ 44.622222] x64sysclose+0x8f/0x120 [ 44.622530] dosyscall64+0x5b/0x2f0 [ 44.622840] entrySYSCALL64afterhwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227

Kernel panics because it detects UFFD inconsistency during userfaultfdreleaseall(). Specifically, a VMA which has a valid pointer to vma->vmuserfaultfdctx, but no UFFD flags in vma->vmflags.

The inconsistency is caused in ksmmadvise(): when user calls madvise() with MADVUNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vmflags.

Assuming x8664 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VMMERGEABLE assignment.

VMMERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vmflags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.

Fix it by changing VMMERGEABLE constant to unsigned long, using the BIT() macro.

Note: other VM flags are not affected: This only happens to the VMMERGEABLE flag, as the other VM flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.

Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM)BUGON()s"), this is no longer a kernel BUG, but a WARNING at the same place:

[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067

but the root-cause (flag-drop) remains the same.

[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]

ceph: fix race condition validating rparent before applying state

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

tcpbpf: Call skmsgfree() when tcpbpfsendverdict() fails to allocate psock->cork.

syzbot reported the splat below. [0]

The repro does the following:

1. Load a skmsg prog that calls bpfmsgcorkbytes(msg, corkbytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than corkbytes

At 5., the data is carried over to the next sendmsg() as it is smaller than the corkbytes specified by bpfmsgcorkbytes().

Then, tcpbpfsendverdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + GFPNOWARN.

If the allocation fails, we need to revert the sk->skforwardalloc change done by skmsgalloc().

Let's call skmsgfree() when tcpbpfsendverdict fails to allocate psock->cork.

The "copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "copied" to 0.

[0]: WARNING: net/ipv4/afinet.c:156 at inetsockdestruct+0x623/0x730 net/ipv4/afinet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inetsockdestruct+0x623/0x730 net/ipv4/afinet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> skdestruct+0x86/0x660 net/core/sock.c:2339 rcudobatch kernel/rcu/tree.c:2605 [inline] rcucore+0xca8/0x1770 kernel/rcu/tree.c:2861 handlesoftirqs+0x286/0x870 kernel/softirq.c:579 dosoftirq kernel/softirq.c:613 [inline] invokesoftirq kernel/softirq.c:453 [inline] irqexitrcu+0xca/0x1f0 kernel/softirq.c:680 irqexitrcu+0x9/0x30 kernel/softirq.c:696 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvecapictimerinterrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>

i40e: fix IRQ freeing in i40evsirequestirqmsix error path

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

net: phylink: add lock for serializing concurrent pl->phydev writes with resolver

Currently phylinkresolve() protects itself against concurrent phylinkbringupphy() or phylinkdisconnectphy() calls which modify pl->phydev by relying on pl->statemutex.

The problem is that in phylinkresolve(), pl->statemutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->statemutex. But that requires dereferencing pl->phydev in the first place, and without pl->statemutex, that is racy.

Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutexlock(&phy->lock) will be moved outside of the mutexlock(&pl->statemutex) section.

Another alternative considered would have been to let phylinkresolve() acquire the rtnlmutex, which is also held when phylinkbringupphy() and phylinkdisconnectphy() are called. But since phylinkdisconnectphy() runs under rtnllock(), it would deadlock with phylinkresolve() when calling flushwork(&pl->resolve). Additionally, it would have been undesirable because it would have unnecessarily blocked many other call paths as well in the entire kernel, so the smaller-scoped lock was preferred.

i40e: remove read access to debugfs files

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

netfilter: brnetfilter: do not check confirmed bit in brnflocalin() after confirm

When send a broadcast packet to a tap device, which was added to a bridge, brnflocalin() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen.

------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/brnetfilterhooks.c:632 brnflocalin+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tapsend Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:brnflocalin+0x168/0x200 Call Trace: <TASK> nfhookslow+0x3e/0xf0 brpassframeup+0x103/0x180 brhandleframefinish+0x2de/0x5b0 brnfhookthresh+0xc0/0x120 brnfpreroutingfinish+0x168/0x3a0 brnfprerouting+0x237/0x5e0 brhandleframe+0x1ec/0x3c0 netifreceiveskbcore+0x225/0x1210 netifreceiveskbonecore+0x37/0xa0 netifreceiveskb+0x36/0x160 tungetuser+0xa54/0x10c0 tunchrwriteiter+0x65/0xb0 vfswrite+0x305/0x410 ksyswrite+0x60/0xd0 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]---

To solve the hash conflict, nfctresolveclash() try to merge the conntracks, and update skb->nfct. However, brnflocalin() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning.

If confirm() does not insert the conntrack entry and return NFDROP, the warning may also occur. There is no need to reserve the WARNONONCE, just remove it.

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

Bluetooth: hcicore: Disable works on hciunregisterdev

This make use of disablework on hciunregisterdev since the hcidev is about to be freed new submissions are not disarable.

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

mm/memory-failure: fix VMBUGONPAGE(PagePoisoned(page)) when unpoison memory

When I did memory failure tests, below panic occurs:

page dumped because: VMBUGONPAGE(PagePoisoned(page)) kernel BUG at include/linux/page-flags.h:616! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40 RIP: 0010:unpoisonmemory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Call Trace: <TASK> unpoisonmemory+0x2f3/0x590 simpleattrwritexsigned.constprop.0.isra.0+0xb3/0x110 debugfsattrwrite+0x42/0x60 fullproxywrite+0x5b/0x80 vfswrite+0xd5/0x540 ksyswrite+0x64/0xe0 dosyscall64+0xb9/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f08f0314887 RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887 RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001 RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 </TASK> Modules linked in: hwpoisoninject ---[ end trace 0000000000000000 ]--- RIP: 0010:unpoisonmemory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---

The root cause is that unpoisonmemory() tries to check the PGHWPoison flags of an uninitialized page. So VMBUGONPAGE(PagePoisoned(page)) is triggered. This can be reproduced by below steps:

1.Offline memory block:

echo offline > /sys/devices/system/memory/memory12/state

2.Get offlined memory pfn:

page-types -b n -rlN

3.Write pfn to unpoison-pfn

echo <pfn> > /sys/kernel/debug/hwpoison/unpoison-pfn

This scenario can be identified by pfntoonlinepage() returning NULL. And ZONEDEVICE pages are never expected, so we can simply fail if pfntoonlinepage() == NULL to fix the bug.

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

wifi: brcmfmac: fix use-after-free when rescheduling brcmfbtcoexinfo work

The brcmfbtcoexdetach() only shuts down the btcoex timer, if the flag timeron is false. However, the brcmfbtcoextimerfunc(), which runs as timer handler, sets timeron to false. This creates critical race conditions:

1.If brcmfbtcoexdetach() is called while brcmfbtcoextimerfunc() is executing, it may observe timeron as false and skip the call to timershutdownsync().

2.The brcmfbtcoextimerfunc() may then reschedule the brcmfbtcoexinfo worker after the cancelworksync() has been executed, resulting in use-after-free bugs.

The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmfbtcoexinfo struct is freed relative to the execution of its worker thread.

Scenario 1: Freed before the worker is scheduled

The brcmfbtcoexinfo is deallocated before the worker is scheduled. A race condition can occur when schedulework(&btlocal->work) is called after the target memory has been freed. The sequence of events is detailed below:

CPU0 | CPU1 brcmfbtcoexdetach | brcmfbtcoextimerfunc | btlocal->timeron = false; if (cfg->btcoex->timeron) | ... | cancelworksync(); | ... | kfree(cfg->btcoex); // FREE | | schedulework(&btlocal->work); // USE

Scenario 2: Freed after the worker is scheduled

The brcmfbtcoexinfo is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmfbtcoexhandler() — such as the containerof macro and subsequent dereferences of the brcmfbtcoexinfo object will cause a use-after-free access. The following timeline illustrates this scenario:

CPU0 | CPU1 brcmfbtcoexdetach | brcmfbtcoextimerfunc | btlocal->timeron = false; if (cfg->btcoex->timeron) | ... | cancelworksync(); | ... | schedulework(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmfbtcoexhandler() // Worker / | btci = containerof(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| / |

To resolve the race conditions, drop the conditional check and call timershutdownsync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timeron state is then set to false.

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

ptp: ocp: fix use-after-free bugs causing by ptpocpwatchdog

The ptpocpdetach() only shuts down the watchdog timer if it is pending. However, if the timer handler is already running, the timerdeletesync() is not called. This leads to race conditions where the devlink that contains the ptpocp is deallocated while the timer handler is still accessing it, resulting in use-after-free bugs. The following details one of the race scenarios.

(thread 1) | (thread 2) ptpocpremove() | ptpocpdetach() | ptpocpwatchdog() if (timerpending(&bp->watchdog))| bp = timercontainerof() timerdeletesync() | | devlinkfree(devlink) //free | | bp-> //use

Resolve this by unconditionally calling timerdeletesync() to ensure the timer is reliably deactivated, preventing any access after free.

i40e: Fix potential invalid access when MAC list is empty

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

vxlan: Fix NPD when refreshing an FDB entry with a nexthop object

VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.

However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].

Fix by dropping such packets earlier. Remove the misleading comment from firstremotercu().

[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlansnoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlanencapbypass+0x209/0x240 encapbypassiflocal+0xb1/0x100 vxlanxmitone+0x1375/0x17e0 vxlanxmit+0x6b4/0x15f0 devhardstartxmit+0x5d/0x1c0 devqueuexmit+0x246/0xfd0 packetsendmsg+0x113a/0x1850 socksendmsg+0x38/0x70 syssendto+0x126/0x180 x64syssendto+0x24/0x30 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x4b/0x53

[2] #!/bin/bash

ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo

ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb

ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning

bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10

mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q

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

vxlan: Fix NPD in {arp,neigh}reduce() when using nexthop objects

When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).

The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].

Fix by checking that the remote destination exists before dereferencing it.

[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlanxmit+0xb58/0x15f0 [...] Call Trace: <TASK> devhardstartxmit+0x5d/0x1c0 devqueuexmit+0x246/0xfd0 packetsendmsg+0x113a/0x1850 socksendmsg+0x38/0x70 syssendto+0x126/0x180 x64syssendto+0x24/0x30 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x4b/0x53

[2] #!/bin/bash

ip address add 192.0.2.1/32 dev lo

ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb

ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy

ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0

bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3

[3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlanxmit+0x803/0x1600 [...] Call Trace: <TASK> devhardstartxmit+0x5d/0x1c0 devqueuexmit+0x246/0xfd0 ip6finishoutput2+0x210/0x6c0 ip6finishoutput+0x1af/0x2b0 ip6mroutput+0x92/0x3e0 ip6sendskb+0x30/0x90 rawv6sendmsg+0xe6e/0x12e0 socksendmsg+0x38/0x70 syssendto+0x126/0x180 x64syssendto+0x24/0x30 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77

[4] #!/bin/bash

ip address add 2001:db8:1::1/128 dev lo

ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb

ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy

ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0

bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0

batman-adv: fix OOB read/write in network-coding decode

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

btrfs: don't check PageError in extentwritepage

extentwritepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O.

Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in extentwritepage by never leaking the error bit into the submission context.

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

iomap: iomap: fix memory corruption when recording errors during writeback

Every now and then I see this crash on arm64:

Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dmthinpool dmpersistentdata XFS (dm-0): Metadata I/O Error (0x1) detected at xfstransreadbufmap+0x1ec/0x590 [xfs] (fs/xfs/xfstransbuf.c:296). dmbioprison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfsimaplookup: xfsiallocreadagi() returned error -5, agno 0 dmbufio dmlogwrites xfs nftchainnat xtREDIRECT nfnat nfconntrack nfdefragipv6 nfdefragipv4 ip6tREJECT potentially unexpected fatal signal 6. nfrejectipv6 potentially unexpected fatal signal 6. iptREJECT nfrejectipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsecgsskrb5 authrpcgss xttcpudp ipsethaship ipsethashnet xtset nftcompat ipsethashmac ipset nftables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) iptables pc : 000003fd6d7df200 xtables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wbworkfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseqset+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : filemapsetwberr+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000

x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseqset+0x1c/0x100 filemapsetwberr+0x24/0xe0 iomapdowritepage+0x5e4/0xd5c writecachepages+0x208/0x674 iomapwritepages+0x34/0x60 xfsvmwritepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---

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

scsi: ufs: core: Fix device management cmd timeout flow

In the UFS error handling flow, the host will send a device management cmd (NOP OUT) to the device for link recovery. If this cmd times out and clearing the doorbell fails, ufshcdwaitfordevcmd() will do nothing and return. hba->devcmd.complete struct is not set to NULL.

When this happens, if cmd has been completed by device, then we will call complete() in ufshcdtransferreqcompl(). Because the complete struct is allocated on the stack, the following crash will occur:

ipanicdie+0x24/0x38 [mrdump] die+0x344/0x748 arm64notifydie+0x44/0x104 dodebugexception+0x104/0x1e0 el1dbg+0x38/0x54 el1synchandler+0x40/0x88 el1sync+0x8c/0x140 queuedspinlockslowpath+0x2e4/0x3c0 ufshcdtransferreqcompl+0x3b0/0x1164 ufshcdtrchandler+0x15c/0x308 ufshcdhostresetandrestore+0x54/0x260 ufshcdresetandrestore+0x28c/0x57c ufshcderrhandler+0xeb8/0x1b6c processonework+0x288/0x964 workerthread+0x4bc/0xc7c kthread+0x15c/0x264 retfromfork+0x10/0x30

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

scsi: mpi3mr: Use number of bits to manage bitmap sizes

To allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps using byte as unit. However, bitmap helper functions assume that bitmaps are allocated using unsigned long as unit. This gap causes memory access beyond the bitmap sizes and results in "BUG: KASAN: slab-out-of-bounds". The BUG was observed at firmware download to eHBA-9600. Call trace indicated that the out-of-bounds access happened in findfirstzerobit() called from mpi3mrsendeventack() for miroc->evtackcmdsbitmap.

To fix the BUG, do not use bytes to manage bitmap sizes. Instead, use number of bits, and call bitmap helper functions which take number of bits as arguments. For memory allocation, call bitmapzalloc() instead of kzalloc() and krealloc(). For memory free, call bitmapfree() instead of kfree(). For zero clear, call bitmapclear() instead of memset().

Remove three fields for bitmap byte sizes in struct scmdpriv which are no longer required. Replace the field devhandlebitmapsz with devhandlebitmapbits to keep number of bits of removependbitmap across resize.