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

octeontx2-af: Workaround SQM/PSE stalls by disabling sticky

NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated.

work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21)

These changes are applied via NIXAFSQMDBGCTLSTATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations.

drm/i915/gt: fix refcount underflow in intelengineparkheartbeat

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

net: cpswnew: Fix potential unregister of netdev that has not been registered yet

If an error occurs during registernetdev() for the first MAC in cpswregisterports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpswunregisterports() to attempt unregistering the second MAC. To address this, add a check for ndev->regstate before calling unregisternetdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.

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

usb: typec: ucsi: validate connector number in ucsinotifycommon()

The connector number extracted from CCI via UCSICCICONNECTOR() is a 7-bit field (0-127) that is used to index into the connector array in ucsiconnectorchange(). However, the array is only allocated for the number of connectors reported by the device (typically 2-4 entries).

A malicious or malfunctioning device could report an out-of-range connector number in the CCI, causing an out-of-bounds array access in ucsiconnectorchange().

Add a bounds check in ucsinotifycommon(), the central point where CCI is parsed after arriving from hardware, so that bogus connector numbers are rejected before they propagate further.

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

netfilter: flowtable: strictly check for maximum number of actions

The maximum number of flowtable hardware offload actions in IPv6 is:

ethernet mangling (4 payload actions, 2 for each ethernet address) SNAT (4 payload actions) DNAT (4 payload actions) Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. Redirect (1 action)

Which makes 17, while the maximum is 16. But actct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions.

Update flowactionentrynext() calls to check for the maximum number of supported actions.

While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.

cgroup: split cgroupdestroywq into 3 workqueues

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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

nbd: don't allow reconnect after disconnect

Following process can cause nbdconfig UAF:

1) grab nbdconfig temporarily;

2) nbdgenldisconnect() flush all recvwork() and release the initial reference:

nbdgenldisconnect nbddisconnectandput nbddisconnect flushworkqueue(nbd->recvworkq) if (testandclearbit(NBDRTHASCONFIGREF, ...)) nbdconfigput -> due to step 1), reference is still not zero

3) nbdgenlreconfigure() queue recvwork() again;

nbdgenlreconfigure config = nbdgetconfigunlocked(nbd) if (!config) -> succeed if (!testbit(NBDRTBOUND, ...)) -> succeed nbdreconnectsocket queuework(nbd->recvworkq, &args->work)

4) step 1) release the reference;

5) Finially, recvwork() will trigger UAF:

recvwork nbdconfigput(nbd) -> nbdconfig is freed atomicdec(&config->recvthreads) -> UAF

Fix the problem by clearing NBDRTBOUND in nbdgenldisconnect(), so that nbdgenlreconfigure() will fail.

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

ndisc: extend RCU protection in ndiscsendskb()

ndiscsendskb() can be called without RTNL or RCU held.

Acquire rcureadlock() earlier, so that we can use devnetrcu() and avoid a potential UAF.

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

ipv6: use RCU protection in ip6defaultadvmss()

ip6defaultadvmss() needs rcu protection to make sure the net structure it reads does not disappear.

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

ipv6: Fix memleak of nhcpcpurthoutput in fibchecknhv6gw().

fibchecknhv6gw() expects that fib6nhinit() cleans up everything when it fails.

Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6nh") moved fibnhcommoninit() before allocpercpugfp() within fib6nhinit() but forgot to add cleanup for fib6nh->nhcommon.nhcpcpurthoutput in case it fails to allocate fib6nh->rt6ipcpu, resulting in memleak.

Let's call fibnhcommonrelease() and clear nhcpcpurthoutput in the error path.

Note that we can remove the fib6nhrelease() call in nhcreateipv6() later in net-next.git.

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

net: gso: fix ownership in udpgsosegment

In udpgsosegment the skb destructor is removed before segmenting the skb but the socket reference is kept as-is. This is an issue if the original skb is later orphaned as we can hit the following bug:

kernel BUG at ./include/linux/skbuff.h:3312! (skborphan) RIP: 0010:iprcvcore+0x8b2/0xca0 Call Trace: iprcv+0xab/0x6e0 netifreceiveskbonecore+0x168/0x1b0 processbacklog+0x384/0x1100 napipoll.constprop.0+0xa1/0x370 netrxaction+0x925/0xe50

The above can happen following a sequence of events when using OpenVSwitch, when an OVSACTIONATTRUSERSPACE action precedes an OVSACTIONATTROUTPUT action:

1. OVSACTIONATTRUSERSPACE is handled (in doexecuteactions): the skb goes through queuegsopackets and then udpgsosegment, where its destructor is removed. 2. The segments' data are copied and sent to userspace. 3. OVSACTIONATTROUTPUT is handled (in doexecuteactions) and the same original skb is sent to its path. 4. If it later hits skborphan, we hit the bug.

Fix this by also removing the reference to the socket in udpgsosegment.

fs: Prevent file descriptor table allocations exceeding INTMAX

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

net: lan743x: Fix memleak issue when GSO enabled

Always map the skb to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak

bpf: Prevent tail call between progs attached to different hooks

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

llc: do not use skbget() before devqueuexmit()

syzbot is able to crash hosts [1], using llc and devices not supporting IFFTXSKBSHARING.

In this case, e1000 driver calls ethskbpad(), while the skb is shared.

Simply replace skbget() by skbclone() in net/llc/llcsac.c

Note that e1000 driver might have an issue with pktgen, because it does not clear IFFTXSKBSHARING, this is an orthogonal change.

We need to audit other skbget() uses in net/llc.

[1]

kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskbexpandhead+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace: <TASK> skbpad+0x18a/0x610 net/core/skbuff.c:2466 skbputpadto include/linux/skbuff.h:3843 [inline] skbputpadto include/linux/skbuff.h:3862 [inline] ethskbpad include/linux/etherdevice.h:656 [inline] e1000xmitframe+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000main.c:3128 netdevstartxmit include/linux/netdevice.h:5151 [inline] netdevstartxmit include/linux/netdevice.h:5160 [inline] xmitone net/core/dev.c:3806 [inline] devhardstartxmit+0x9a/0x7b0 net/core/dev.c:3822 schdirectxmit+0x1ae/0xc30 net/sched/schgeneric.c:343 devxmitskb net/core/dev.c:4045 [inline] devqueuexmit+0x13d4/0x43e0 net/core/dev.c:4621 devqueuexmit include/linux/netdevice.h:3313 [inline] llcsapactionsendtestc+0x268/0x320 net/llc/llcsac.c:144 llcexecsaptransactions net/llc/llcsap.c:153 [inline] llcsapnextstate net/llc/llcsap.c:182 [inline] llcsapstateprocess+0x239/0x510 net/llc/llcsap.c:209 llcuisendmsg+0xd0d/0x14e0 net/llc/afllc.c:993 socksendmsgnosec net/socket.c:718 [inline]

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

pfifotailenqueue: Drop new packet when sch->limit == 0

Expected behaviour: In case we reach scheduler's limit, pfifotailenqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifotailenqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifotailenqueue() return NETXMITCN status code.

Weird behaviour: In case we set sch->limit == 0 and trigger pfifotailenqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifotailenqueue() to increase qlen by one and return NETXMITCN status code.

The problem is: Let's say we have two qdiscs: QdiscA and QdiscB. - QdiscA's type must have '->graft()' function to create parent/child relationship. Let's say QdiscA's type is hfsc. Enqueue packet to this qdisc will trigger hfscenqueue. - QdiscB's type is pfifoheaddrop. Enqueue packet to this qdisc will trigger pfifotailenqueue. - QdiscB is configured to have sch->limit == 0. - QdiscA is configured to route the enqueued's packet to QdiscB.

Enqueue packet through QdiscA will lead to: - hfscenqueue(QdiscA) -> pfifotailenqueue(QdiscB) - QdiscB->q.qlen += 1 - pfifotailenqueue() return NETXMITCN - hfscenqueue() check for NETXMITSUCCESS and see NETXMITCN => hfscenqueue() don't increase qlen of QdiscA.

The whole process lead to a situation where QdiscA->q.qlen == 0 and QdiscB->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.

Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.

fs/buffer: fix use-after-free when call bhread() helper

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

SUNRPC: svcauthgss: avoid NULL deref on zero length gsstoken in gssreadproxyverf

A zero length gsstoken results in pages == 0 and intoken->pages[0] is NULL. The code unconditionally evaluates pageaddress(intoken->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.

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

pps: Fix a use-after-free

On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sysexit() from gpsd when rebooting:

pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobjectput() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobjectput+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobjectput+0x120/0x150 lr : kobjectput+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobjectput+0x120/0x150 cdevput+0x20/0x3c fput+0x2c4/0x2d8 fput+0x1c/0x38 taskworkrun+0x70/0xfc doexit+0x2a0/0x924 dogroupexit+0x34/0x90 getsignal+0x7fc/0x8c0 dosignal+0x128/0x13b4 donotifyresume+0xdc/0x160 el0svc+0xd4/0xf8 el0t64synchandler+0x140/0x14c el0t64sync+0x190/0x194 ---[ end trace 0000000000000000 ]---

...followed by more symptoms of corruption, with similar stacks:

refcountt: underflow; use-after-free. kernel BUG at lib/listdebug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception

This happens because ppsdevicedestruct() frees the ppsdevice with the embedded cdev immediately after calling cdevdel(), but, as the comment above cdevdel() notes, fops for previously opened cdevs are still callable even after cdevdel() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board.

In commit d953e0e837e6 ("pps: Fix a use-after free bug when unregistering a source."), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using registerchrdev() with ppsidr becoming the source of truth for which minor corresponds to which device.

But now that ppsidr defines userspace visibility instead of cdevadd(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idrremove() call moves to ppsunregistercdev(), and ppsidr now holds a reference to pps->dev.

ppscore: source serial1 got cdev (251:1) <...> pps pps1: removed ppscore: unregistering pps1 ppscore: deallocating pps1

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

thermal: int340x: Add NULL check for adev

Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL").

Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402thermalprobe().

Note, under the same directory, int3400thermalprobe() has such a check.

[ rjw: Subject edit, added Fixes: ]

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

netfilter: nfconncount: Fully initialize struct nfconncounttuple in inserttree()

Since commit b36e4523d4d5 ("netfilter: nfconncount: fix garbage collection confirm race"), cpu and jiffies32 were introduced to the struct nfconncounttuple.

The commit made nfconncountadd() initialize conn->cpu and conn->jiffies32 when allocating the struct. In contrast, counttree() was not changed to initialize them.

By commit 34848d5c896e ("netfilter: nfconncount: Split insert and traversal"), counttree() was split and the relevant allocation code now resides in inserttree(). Initialize conn->cpu and conn->jiffies32 in inserttree().

BUG: KMSAN: uninit-value in findorevict net/netfilter/nfconncount.c:117 [inline] BUG: KMSAN: uninit-value in nfconncountadd+0xd9c/0x2850 net/netfilter/nfconncount.c:143 findorevict net/netfilter/nfconncount.c:117 [inline] nfconncountadd+0xd9c/0x2850 net/netfilter/nfconncount.c:143 counttree net/netfilter/nfconncount.c:438 [inline] nfconncountcount+0x82f/0x1e80 net/netfilter/nfconncount.c:521 connlimitmt+0x7f6/0xbd0 net/netfilter/xtconnlimit.c:72 nftmatcheval net/netfilter/nftcompat.c:403 [inline] nftmatcheval+0x1a5/0x300 net/netfilter/nftcompat.c:433 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x426/0x2290 net/netfilter/nftablescore.c:288 nftdochainipv4+0x1a5/0x230 net/netfilter/nftchainfilter.c:23 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhookslowlist+0x24d/0x860 net/netfilter/core.c:663 NFHOOKLIST include/linux/netfilter.h:350 [inline] ipsublistrcv+0x17b7/0x17f0 net/ipv4/ipinput.c:633 iplistrcv+0x9ef/0xa40 net/ipv4/ipinput.c:669 netifreceiveskblistptype net/core/dev.c:5936 [inline] netifreceiveskblistcore+0x15c5/0x1670 net/core/dev.c:5983 netifreceiveskblist net/core/dev.c:6035 [inline] netifreceiveskblistinternal+0x1085/0x1700 net/core/dev.c:6126 netifreceiveskblist+0x5a/0x460 net/core/dev.c:6178 xdprecvframes net/bpf/testrun.c:280 [inline] xdptestrunbatch net/bpf/testrun.c:361 [inline] bpftestrunxdplive+0x2e86/0x3480 net/bpf/testrun.c:390 bpfprogtestrunxdp+0xf1d/0x1ae0 net/bpf/testrun.c:1316 bpfprogtestrun+0x5e5/0xa30 kernel/bpf/syscall.c:4407 sysbpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 dosysbpf kernel/bpf/syscall.c:5902 [inline] sesysbpf kernel/bpf/syscall.c:5900 [inline] ia32sysbpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32syscall+0x394d/0x4180 arch/x86/include/generated/asm/syscalls32.h:358 dosyscall32irqson arch/x86/entry/common.c:165 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/common.c:387 dofastsyscall32+0x38/0x80 arch/x86/entry/common.c:412 doSYSENTER32+0x1f/0x30 arch/x86/entry/common.c:450 entrySYSENTERcompatafterhwframe+0x84/0x8e

Uninit was created at: slabpostallochook mm/slub.c:4121 [inline] slaballocnode mm/slub.c:4164 [inline] kmemcacheallocnoprof+0x915/0xe10 mm/slub.c:4171 inserttree net/netfilter/nfconncount.c:372 [inline] counttree net/netfilter/nfconncount.c:450 [inline] nfconncountcount+0x1415/0x1e80 net/netfilter/nfconncount.c:521 connlimitmt+0x7f6/0xbd0 net/netfilter/xtconnlimit.c:72 nftmatcheval net/netfilter/nftcompat.c:403 [inline] nftmatcheval+0x1a5/0x300 net/netfilter/nftcompat.c:433 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x426/0x2290 net/netfilter/nftablescore.c:288 nftdochainipv4+0x1a5/0x230 net/netfilter/nftchainfilter.c:23 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhookslowlist+0x24d/0x860 net/netfilter/core.c:663 NFHOOKLIST include/linux/netfilter.h:350 [inline] ipsublistrcv+0x17b7/0x17f0 net/ipv4/ipinput.c:633 iplistrcv+0x9ef/0xa40 net/ip ---truncated---

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

ndisc: use RCU protection in ndiscallocskb()

ndiscallocskb() can be called without RTNL or RCU being held.

Add RCU protection to avoid possible UAF.

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

tcp: Clear tcpsk(sk)->fastopenrsk in tcpdisconnect().

syzbot reported the splat below where a socket had tcpsk(sk)->fastopenrsk in the TCPESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS:

1. accept() 2. connect(AFUNSPEC) 3. connect() to another destination

As of accept(), sk->skstate is TCPSYNRECV, and tcpdisconnect() changes it to TCPCLOSE and makes connect() possible, which restarts timers.

Since tcpdisconnect() forgot to clear tcpsk(sk)->fastopenrsk, the retransmit timer triggered the warning and the intended packet was not retransmitted.

Let's call reqskfastopenremove() in tcpdisconnect().

[0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcptimer.c:542 tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcpwritetimer (net/ipv4/tcptimer.c:738) calltimerfn (kernel/time/timer.c:1747) runtimers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timerexpireremote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigrhandleremoteup (kernel/time/timermigration.c:944 kernel/time/timermigration.c:1035) walkgroups.isra.0 (kernel/time/timermigration.c:533 (discriminator 1)) tmigrhandleremote (kernel/time/timermigration.c:1096) handlesoftirqs (./arch/x86/include/asm/jumplabel.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irqexitrcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ>

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

ubifs: skip dumping tnc tree when zroot is null

Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.

futex: Clear stale exiting pointer in futexlockpi() retry path

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

nfc: pn533: allocate rx skb before consuming bytes

pn532receivebuf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recvskb and may already hand a complete frame to pn533recvframe() before allocating a fresh receive buffer.

If that allocskb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recvskb as NULL for the next receive callback. That breaks the receivebuf() accounting contract and can also lead to a NULL dereference on the next skbputu8().

Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.

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

openvswitch: validate MPLS set/setmasked payload length

validateset() accepted OVSKEYATTRMPLS as variable-sized payload for SET/SETMASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovskeympls).

Use the already normalized keylen (masked case included) and reject non-matching MPLS action key sizes.

Reject invalid MPLS action payload lengths early.

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

NFC: pn533: bound the UART receive buffer

pn532receivebuf() appends every incoming byte to dev->recvskb and only resets the buffer after pn532uartrxisframe() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skbputu8() hits the tail limit.

Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532UARTSKBBUFFLEN.

A use-after-free exists in drivers/tee/teeshm.c in the TEE subsystem in the Linux kernel through 5.15.11. This occurs because of a race condition in teeshmgetfromid during an attempt to free a shared memory object.