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

svcrdma: bound check rqpages index in inline path

svcrdmacopyinlinerange indexed rqstp->rqpages[rccurpage] without verifying rccurpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.

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

ip6gre: make ip6greheader() robust

Over the years, syzbot found many ways to crash the kernel in ip6greheader() [1].

This involves team or bonding drivers ability to dynamically change their dev->neededheadroom and/or dev->hardheaderlen

In this particular crash mldnewpack() allocated an skb with a too small reserve/headroom, and by the time mldsendpack() was called, syzbot managed to attach an ip6gre device.

[1] skbuff: skbunderpanic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! <TASK> skbunderpanic net/core/skbuff.c:223 [inline] skbpush+0xc3/0xe0 net/core/skbuff.c:2641 ip6greheader+0xc8/0x790 net/ipv6/ip6gre.c:1371 devhardheader include/linux/netdevice.h:3436 [inline] neighconnectedoutput+0x286/0x460 net/core/neighbour.c:1618 neighoutput include/net/neighbour.h:556 [inline] ip6finishoutput2+0xfb3/0x1480 net/ipv6/ip6output.c:136 ip6finishoutput net/ipv6/ip6output.c:-1 [inline] ip6finishoutput+0x234/0x7d0 net/ipv6/ip6output.c:220 NFHOOKCOND include/linux/netfilter.h:307 [inline] ip6output+0x340/0x550 net/ipv6/ip6output.c:247 NFHOOK+0x9e/0x380 include/linux/netfilter.h:318 mldsendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mldsendcr net/ipv6/mcast.c:2154 [inline] mldifcwork+0x83e/0xd60 net/ipv6/mcast.c:2693

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

libceph: prevent potential out-of-bounds reads in handleauthdone()

Perform an explicit bounds check on payloadlen to avoid a possible out-of-bounds access in the callout.

[ idryomov: changelog ]

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

btrfs: fix use-after-free warning in btrfsgetorcreatedelayednode()

Previously, btrfsgetorcreatedelayednode() set the delayednode's refcount before acquiring the root->delayednodes lock. Commit e8513c012de7 ("btrfs: implement reftracker for delayednodes") moved refcountset inside the critical section, which means there is no longer a memory barrier between setting the refcount and setting btrfsinode->delayednode.

Without that barrier, the stores to node->refs and btrfsinode->delayednode may become visible out of order. Another thread can then read btrfsinode->delayednode and attempt to increment a refcount that hasn't been set yet, leading to a refcounting bug and a use-after-free warning.

The fix is to move refcountset back to where it was to take advantage of the implicit memory barrier provided by lock acquisition.

Because the allocations now happen outside of the lock's critical section, they can use GFPNOFS instead of GFPATOMIC.

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

nvmet-tcp: add bounds checks in nvmettcpbuildpduiovec

nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to copytoiter() GPF/KASAN. Guard sgidx, remaining entries, and sg->length/offset before building the bvec.

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

inet: frags: fix use-after-free caused by the fqdirpreexit() flush

On netns teardown, fqdirpreexit() walks the fqdir rhashtable and flushes every fragment queue that is not yet complete using inetfragqueueflush(). That helper frees all the skbs queued on the fragment queue but does not set INETFRAGCOMPLETE, and leaves q->fragmentstail and q->lastrunhead pointing at the freed skbs. The queue itself stays in the rhashtable.

fqdirpreexit() first lowers highthresh to 0 to stop new queue lookups, but it cannot stop a fragment that already obtained the queue through inetfragfind() earlier and stalled just before taking the queue lock. Once that fragment resumes after the flush and takes the queue lock, it passes the INETFRAGCOMPLETE check and then dereferences the freed fragmentstail. inetfragqueueinsert() reads FRAGCB() and ->len of that pointer and, on the append path, writes ->nextfrag, causing a slab use-after-free. IPv6, nfconntrackreasm6 and 6lowpan reassembly share the same flush path and are affected as well.

Reset rbfragments, fragmentstail and lastrunhead in inetfragqueueflush() so a flushed queue no longer points at the freed skbs. A fragment that resumes after the flush and takes the queue lock then finds an empty queue and starts a new run instead of dereferencing the freed fragmentstail. ipfragreinit() already performed this reset after its own flush, so drop the now duplicate code there.

e1000: fix OOB in e1000tbishouldaccept()

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

net: stmmac: fix the crash issue for zero copy XDPTX action

There is a crash issue when running zero copy XDPTX action, the crash log is shown below.

[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000 [ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP [ 216.301694] Call trace: [ 216.304130] dcachecleanpoc+0x20/0x38 (P) [ 216.308308] dmasyncsinglefordevice+0x1bc/0x1e0 [ 216.313351] stmmacxdpxmitxdpf+0x354/0x400 [ 216.317701] stmmacxdprunprog+0x164/0x368 [ 216.322139] stmmacnapipollrxtx+0xba8/0xf00 [ 216.326576] napipoll+0x40/0x218 [ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt

For XDPTX action, the xdpbuff is converted to xdpframe by xdpconvertbufftoframe(). The memory type of the resulting xdpframe depends on the memory type of the xdpbuff. For page pool based xdpbuff it produces xdpframe with memory type MEMTYPEPAGEPOOL. For zero copy XSK pool based xdpbuff it produces xdpframe with memory type MEMTYPEPAGEORDER0. However, stmmacxdpxmitback() does not check the memory type and always uses the page pool type, this leads to invalid mappings and causes the crash. Therefore, check the xdpbuff memory type in stmmacxdpxmitback() to fix this issue.

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

libceph: make decodepool() more resilient against corrupted osdmaps

If the osdmap is (maliciously) corrupted such that the encoded length of cephpgpool envelope is less than what is expected for a particular encoding version, out-of-bounds reads may ensue because the only bounds check that is there is based on that length value.

This patch adds explicit bounds checks for each field that is decoded or skipped.

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

btrfs: always detect conflicting inodes when logging inode refs

After rename exchanging (either with the rename exchange operation or regular renames in multiple non-atomic steps) two inodes and at least one of them is a directory, we can end up with a log tree that contains only of the inodes and after a power failure that can result in an attempt to delete the other inode when it should not because it was not deleted before the power failure. In some case that delete attempt fails when the target inode is a directory that contains a subvolume inside it, since the log replay code is not prepared to deal with directory entries that point to root items (only inode items).

1) We have directories "dir1" (inode A) and "dir2" (inode B) under the same parent directory;

2) We have a file (inode C) under directory "dir1" (inode A);

3) We have a subvolume inside directory "dir2" (inode B);

4) All these inodes were persisted in a past transaction and we are currently at transaction N;

5) We rename the file (inode C), so at btrfslognewname() we update inode C's lastunlinktrans to N;

6) We get a rename exchange for "dir1" (inode A) and "dir2" (inode B), so after the exchange "dir1" is inode B and "dir2" is inode A. During the rename exchange we call btrfslognewname() for inodes A and B, but because they are directories, we don't update their lastunlinktrans to N;

7) An fsync against the file (inode C) is done, and because its inode has a lastunlinktrans with a value of N we log its parent directory (inode A) (through btrfslogallparents(), called from btrfsloginodeparent()).

8) So we end up with inode B not logged, which now has the old name of inode A. At copyinodeitemstolog(), when logging inode A, we did not check if we had any conflicting inode to log because inode A has a generation lower than the current transaction (created in a past transaction);

9) After a power failure, when replaying the log tree, since we find that inode A has a new name that conflicts with the name of inode B in the fs tree, we attempt to delete inode B... this is wrong since that directory was never deleted before the power failure, and because there is a subvolume inside that directory, attempting to delete it will fail since replaydirdeletes() and btrfsunlinkinode() are not prepared to deal with dir items that point to roots instead of inodes.

When that happens the mount fails and we get a stack trace like the following:

[87.2314] BTRFS info (device dm-0): start tree-log replay [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259 [87.2332] ------------[ cut here ]------------ [87.2338] BTRFS: Transaction aborted (error -2) [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 btrfsunlinkinode+0x416/0x440 [btrfs] [87.2368] Modules linked in: btrfs loop dmthinpool (...) [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full) [87.2489] Tainted: [W]=WARN [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [87.2514] RIP: 0010:btrfsunlinkinode+0x416/0x440 [btrfs] [87.2538] Code: c0 89 04 24 (...) [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286 [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000 [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840 [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0 [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10 [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000 [87. ---truncated---

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

net: hns3: add VLAN id validation before using

Currently, the VLAN id may be used without validation when receive a VLAN configuration mailbox from VF. The length of vlandelfailbmap is BITSTOLONGS(VLANNVID). It may cause out-of-bounds memory access once the VLAN id is bigger than or equal to VLANNVID.

Therefore, VLAN id needs to be checked to ensure it is within the range of VLANNVID.

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

netrom: fix double-free in nrrouteframe()

In nrrouteframe(), oldskb is immediately freed without checking if nrneigh->ax25 pointer is NULL. Therefore, if nrneigh->ax25 is NULL, the caller function will free oldskb again, causing a double-free bug.

Therefore, to prevent this, we need to modify it to check whether nrneigh->ax25 is NULL before freeing oldskb.

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

scsi: target: iscsi: Fix use-after-free in iscsitdecsessionusagecount()

In iscsitdecsessionusagecount(), the function calls complete() while holding the sess->sessionusagelock. Similar to the connection usage count logic, the waiter signaled by complete() (e.g., in the session release path) may wake up and free the iscsitsession structure immediately.

This creates a race condition where the current thread may attempt to execute spinunlockbh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free.

To resolve this, release the sessionusagelock before calling complete() to ensure all dereferences of the sess pointer are finished before the waiter is allowed to proceed with deallocation.

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

net: wwan: t7xx: fix potential skb->frags overflow in RX path

When receiving data in the DPMAIF RX path, the t7xxdpmaifsetfragtoskb() function adds page fragments to an skb without checking if the number of fragments has exceeded MAXSKBFRAGS. This could lead to a buffer overflow in skbshinfo(skb)->frags[] array, corrupting adjacent memory and potentially causing kernel crashes or other undefined behavior.

This issue was identified through static code analysis by comparing with a similar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76: fix array overflow on receiving too many fragments for a packet").

The vulnerability could be triggered if the modem firmware sends packets with excessive fragments. While under normal protocol conditions (MTU 3080 bytes, BAT buffer 3584 bytes), a single packet should not require additional fragments, the kernel should not blindly trust firmware behavior. Malicious, buggy, or compromised firmware could potentially craft packets with more fragments than the kernel expects.

Fix this by adding a bounds check before calling skbaddrxfrag() to ensure nrfrags does not exceed MAXSKBFRAGS.

The check must be performed before unmapping to avoid a page leak and double DMA unmap during device teardown.

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

scsi: target: iscsi: Fix use-after-free in iscsitdecconnusagecount()

In iscsitdecconnusagecount(), the function calls complete() while holding the conn->connusagelock. As soon as complete() is invoked, the waiter (such as iscsitcloseconnection()) may wake up and proceed to free the iscsitconn structure.

If the waiter frees the memory before the current thread reaches spinunlockbh(), it results in a KASAN slab-use-after-free as the function attempts to release a lock within the already-freed connection structure.

Fix this by releasing the spinlock before calling complete().

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

shmem: fix recovery on rename failures

mapletree insertions can fail if we are seriously short on memory; simpleoffsetrename() does not recover well if it runs into that. The same goes for simpleoffsetrenameexchange().

Moreover, shmemwhiteout() expects that if it succeeds, the caller will progress to dmove(), i.e. that shmemrename2() won't fail past the successful call of shmemwhiteout().

Not hard to fix, fortunately - mtreestore() can't fail if the index we are trying to store into is already present in the tree as a singleton.

For simpleoffsetrenameexchange() that's enough - we just need to be careful about the order of operations.

For simpleoffsetrename() solution is to preinsert the target into the tree for newdir; the rest can be done without any potentially failing operations.

That preinsertion has to be done in shmemrename2() rather than in simpleoffsetrename() itself - otherwise we'd need to deal with the possibility of failure after successful shmemwhiteout().

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

net: rose: fix invalid array index in rosekillbydevice()

rosekillbydevice() collects sockets into a local array[] and then iterates over them to disconnect sockets bound to a device being brought down.

The loop mistakenly indexes array[cnt] instead of array[i]. For cnt < ARRAYSIZE(array), this reads an uninitialized entry; for cnt == ARRAYSIZE(array), it is an out-of-bounds read. Either case can lead to an invalid socket pointer dereference and also leaks references taken via sockhold().

Fix the index to use i.

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

iommu/mediatek: fix use-after-free on probe deferral

The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers.

Fix this by keeping the references as expected while the iommu driver is bound.

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

scsi: aic94xx: fix use-after-free in device removal path

The asdpciremove() function fails to synchronize with pending tasklets before freeing the asdha structure, leading to a potential use-after-free vulnerability.

When a device removal is triggered (via hot-unplug or module unload), race condition can occur.

The fix adds taskletkill() before freeing the asdha structure, ensuring all scheduled tasklets complete before cleanup proceeds.

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

RDMA/bnxtre: Fix OOB write in bnxtrecopyerrstats()

Commit ef56081d1864 ("RDMA/bnxtre: RoCE related hardware counters update") added three new counters and placed them after BNXTREOUTOFSEQERR.

BNXTREOUTOFSEQERR acts as a boundary marker for allocating hardware statistics with different numcounters values on chipgenp5p7 devices.

As a result, BNXTRENUMSTDCOUNTERS are used when allocating hwstats, which leads to an out-of-bounds write in bnxtrecopyerrstats().

The counters BNXTREREQCQEERROR, BNXTRERESPCQEERROR, and BNXTRERESPREMOTEACCESSERRS are applicable to generic hardware, not only p5/p7 devices.

Fix this by moving these counters before BNXTREOUTOFSEQERR so they are included in the generic counter set.

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

Input: lkkbd - disable pending work before freeing device

lkkbdinterrupt() schedules lk->tq via schedulework(), and the work handler lkkbdreinit() dereferences the lkkbd structure and its serio/inputdev fields.

lkkbddisconnect() and error paths in lkkbdconnect() free the lkkbd structure without preventing the reinit work from being queued again until serioclose() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.

Use disableworksync() instead of cancelworksync() to ensure the reinit work cannot be re-queued, and call it both in lkkbddisconnect() and in lkkbdconnect() error paths after serioopen().

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

drm/xe/oa: Fix potential UAF in xeoaaddconfigioctl()

In xeoaaddconfigioctl(), we accessed oaconfig->id after dropping metricslock. Since this lock protects the lifetime of oaconfig, an attacker could guess the id and call xeoaremoveconfigioctl() with perfect timing, freeing oaconfig before we dereference it, leading to a potential use-after-free.

Fix this by caching the id in a local variable while holding the lock.

v2: (Matt A) - Dropped mutexunlock(&oa->metricslock) ordering change from xeoaremoveconfigioctl()

(cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31)

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

wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cutxfilldesc()

TID getting from ieee80211gettid() might be out of range of array size of staentry->tids[], so check TID is less than MAXTIDCOUNT. Othwerwise, UBSAN warn:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 index 10 is out of range for type 'rtltiddata [9]'

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

team: fix check for port enabled in teamqueueoverrideportpriochanged()

There has been a syzkaller bug reported recently with the following trace:

listdel corruption, ffff888058bea080->prev is LISTPOISON2 (dead000000000122) ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:59! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:listdelentryvalidorreport+0x13e/0x200 lib/listdebug.c:59 Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000 RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005 RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230 R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480 FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0 Call Trace: <TASK> listdelentryvalid include/linux/list.h:132 [inline] listdelentry include/linux/list.h:223 [inline] listdelrcu include/linux/rculist.h:178 [inline] teamqueueoverrideportdel drivers/net/team/teamcore.c:826 [inline] teamqueueoverrideportdel drivers/net/team/teamcore.c:821 [inline] teamqueueoverrideportpriochanged drivers/net/team/teamcore.c:883 [inline] teampriorityoptionset+0x171/0x2f0 drivers/net/team/teamcore.c:1534 teamoptionset drivers/net/team/teamcore.c:376 [inline] teamnloptionssetdoit+0x8ae/0xe60 drivers/net/team/teamcore.c:2653 genlfamilyrcvmsgdoit+0x209/0x2f0 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x55c/0x800 net/netlink/genetlink.c:1210 netlinkrcvskb+0x158/0x420 net/netlink/afnetlink.c:2552 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1320 [inline] netlinkunicast+0x5aa/0x870 net/netlink/afnetlink.c:1346 netlinksendmsg+0x8c8/0xdd0 net/netlink/afnetlink.c:1896 socksendmsgnosec net/socket.c:727 [inline] socksendmsg net/socket.c:742 [inline] syssendmsg+0xa98/0xc70 net/socket.c:2630 syssendmsg+0x134/0x1d0 net/socket.c:2684 syssendmsg+0x16d/0x220 net/socket.c:2716 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xfa0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

The problem is in this flow: 1) Port is enabled, queueid != 0, in qomlist 2) Port gets disabled -> teamportdisable() -> teamqueueoverrideportdel() -> del (removed from list) 3) Port is disabled, queueid != 0, not in any list 4) Priority changes -> teamqueueoverrideportpriochanged() -> checks: port disabled && queueid != 0 -> calls del - hits the BUG as it is removed already

To fix this, change the check in teamqueueoverrideportpriochanged() so it returns early if port is not enabled.

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

powerpc/64s/slb: Fix SLB multihit issue during SLB preload

On systems using the hash MMU, there is a software SLB preload cache that mirrors the entries loaded into the hardware SLB buffer. This preload cache is subject to periodic eviction — typically after every 256 context switches — to remove old entry.

To optimize performance, the kernel skips switchmmucontext() in switchmmirqsoff() when the prev and next mmstruct are the same. However, on hash MMU systems, this can lead to inconsistencies between the hardware SLB and the software preload cache.

If an SLB entry for a process is evicted from the software cache on one CPU, and the same process later runs on another CPU without executing switchmmucontext(), the hardware SLB may retain stale entries. If the kernel then attempts to reload that entry, it can trigger an SLB multi-hit error.

The following timeline shows how stale SLB entries are created and can cause a multi-hit error when a process moves between CPUs without a MMU context switch.

CPU 0 CPU 1 ----- ----- Process P exec swapper/1 loadelfbinary beginnewexc activatemm switchmmirqsoff switchmmucontext switchslb / This invalidates all the entries in the HW and setup the new HW SLB entries as per the preload cache. / contextswitch schedmigratetask migrates process P to cpu-1

Process swapper/0 context switch (to process P) (uses mmstruct of Process P) switchmmirqsoff() switchslb loadslb++ / loadslb becomes 0 here and we evict an entry from the preload cache with preloadage(). We still keep HW SLB and preload cache in sync, that is because all HW SLB entries anyways gets evicted in switchslb during SLBIA. We then only add those entries back in HW SLB, which are currently present in preloadcache (after eviction). / loadelfbinary continues... setupnewexec() slbsetupnewexec()

schedswitch event schedmigratetask migrates process P to cpu-0

contextswitch from swapper/0 to Process P switchmmirqsoff() / Since both prev and next mm struct are same we don't call switchmmucontext(). This will cause the HW SLB and SW preload cache to go out of sync in preloadnewslbcontext. Because there was an SLB entry which was evicted from both HW and preload cache on cpu-1. Now later in preloadnewslbcontext(), when we will try to add the same preload entry again, we will add this to the SW preload cache and then will add it to the HW SLB. Since on cpu-0 this entry was never invalidated, hence adding this entry to the HW SLB will cause a SLB multi-hit error. / loadelfbinary cont ---truncated---

Bluetooth: btusb: revert use of devmkzalloc in btusb

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

functionfs: fix the open/removal races

ffsepfileopen() can race with removal, ending up with file->privatedata pointing to freed object.

There is a total count of opened files on functionfs (both ep0 and dynamic ones) and when it hits zero, dynamic files get removed. Unfortunately, that removal can happen while another thread is in ffsepfileopen(), but has not incremented the count yet. In that case open will succeed, leaving us with UAF on any subsequent read() or write().

The root cause is that ffs->opened is misused; atomicdecandtest() vs. atomicaddreturn() is not a good idea, when object remains visible all along.

To untangle that serialize openers on ffs->mutex (both for ep0 and for dynamic files) have dynamic ones use atomicincnotzero() and fail if we had zero ->opened; in that case the file we are opening is doomed. have the inodes of dynamic files marked on removal (from the callback of simplerecursiveremoval()) - clear ->iprivate there. have open of dynamic ones verify they hadn't been already removed, along with checking that state is FFSACTIVE.

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

mm/slub: reset KASAN tag in deferfree() before accessing freed memory

When CONFIGSLUBTINY is enabled, kfreenolock() calls kasanslabfree() before deferfree(). On ARM64 with MTE (Memory Tagging Extension), kasanslabfree() poisons the memory and changes the tag from the original (e.g., 0xf3) to a poison tag (0xfe).

When deferfree() then tries to write to the freed object to build the deferred free list via llistadd(), the pointer still has the old tag, causing a tag mismatch and triggering a KASAN use-after-free report:

BUG: KASAN: slab-use-after-free in deferfree+0x3c/0xbc mm/slub.c:6537 Write at addr f3f000000854f020 by task kworker/u8:6/983 Pointer tag: [f3], memory tag: [fe]

Fix this by calling kasanresettag() before accessing the freed memory. This is safe because deferfree() is part of the allocator itself and is expected to manipulate freed memory for bookkeeping purposes.

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

iommufd/selftest: Check for overflow in IOMMUTESTOPADDRESERVED

syzkaller found it could overflow math in the test infrastructure and cause a WARNON by corrupting the reserved interval tree. This only effects test kernels with CONFIGIOMMUFDTEST.

Validate the user input length in the test ioctl.

clk: samsung: exynos-clkout: Assign .num before accessing .hws