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

net: stmmac: dwmac-tegra: Read iommu stream id from device tree

Nvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be written to the MGBEWRAPAXIASID0CTRL register.

The current driver is hard coded to use MGBE0's SID for all controllers. This causes softirq time outs and kernel panics when using controllers other than MGBE0.

Example dmesg errors when an ethernet cable is connected to MGBE1:

[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms [ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter. [ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEMTYPEPAGEPOOL RxQ-0 [ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171) [ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features [ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported [ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock [ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode [ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 181.921198] rcu: INFO: rcupreempt detected stalls on CPUs/tasks: [ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337 [ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8) [ 181.921878] Sending NMI from CPU 4 to CPUs 7: [ 181.921886] NMI backtrace for cpu 7 [ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6 [ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024 [ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 181.922847] pc : handlesoftirqs+0x98/0x368 [ 181.922978] lr : dosoftirq+0x18/0x20 [ 181.923095] sp : ffff80008003bf50 [ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000 [ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0 [ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70 [ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000 [ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000 [ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d [ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160 [ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74 [ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1 [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000 [ 181.967591] Call trace: [ 181.970043] handlesoftirqs+0x98/0x368 (P) [ 181.974240] dosoftirq+0x18/0x20 [ 181.977743] dosoftirq+0x14/0x28 [ 181.981415] callonirqstack+0x24/0x30 [ 181.985180] dosoftirqownstack+0x20/0x30 [ 181.989379] irqexitrcu+0x114/0x140 [ 181.993142] irqexitrcu+0x14/0x28 [ 181.996816] el1interrupt+0x44/0xb8 [ 182.000316] el1h64irqhandler+0x14/0x20 [ 182.004343] el1h64irq+0x80/0x88 [ 182.007755] cpuidleenterstate+0xc4/0x4a8 (P) [ 182.012305] cpuidleenter+0x3c/0x58 [ 182.015980] cpuidleidlecall+0x128/0x1c0 [ 182.020005] doidle+0xe0/0xf0 [ 182.023155] cpustartupentry+0x3c/0x48 [ 182.026917] secondarystartkernel+0xdc/0x120 [ 182.031379] secondaryswitched+0x74/0x78 [ 212.971162] rcu: INFO: rcupreempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/. [ 212.985935] rcu: blocking rcunode structures (internal RCU debug): [ 212.992758] Sending NMI from CPU 0 to CPUs 7: [ 212.998539] NMI backtrace for cpu 7 [ 213.004304] CPU: 7 UID: 0 PI ---truncated---

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

net/smc: fix LGR and link use-after-free issue

We encountered a LGR/link use-after-free issue, which manifested as the LGR/link refcnt reaching 0 early and entering the clear process, making resource access unsafe.

refcountt: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcountwarnsaturate+0x9c/0x140 Workqueue: events smclgrterminatework [smc] Call trace: refcountwarnsaturate+0x9c/0x140 smclgrterminate.part.45+0x2a8/0x370 [smc] smclgrterminatework+0x28/0x30 [smc] processonework+0x1b8/0x420 workerthread+0x158/0x510 kthread+0x114/0x118

or

refcountt: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcountwarnsaturate+0xf0/0x140 Workqueue: smchswq smclistenwork [smc] Call trace: refcountwarnsaturate+0xf0/0x140 smcrlinkput+0x1cc/0x1d8 [smc] smcconnfree+0x110/0x1b0 [smc] smcconnabort+0x50/0x60 [smc] smclistenfinddevice+0x75c/0x790 [smc] smclistenwork+0x368/0x8a0 [smc] processonework+0x1b8/0x420 workerthread+0x158/0x510 kthread+0x114/0x118

It is caused by repeated release of LGR/link refcnt. One suspect is that smcconnfree() is called repeatedly because some smcconnfree() from server listening path are not protected by sock lock.

e.g.

Calls under socklock | smclistenwork ------------------------------------------------------- locksock(sk) | smcconnabort smcconnfree | \- smcconnfree \- smcrlinkput | \- smcrlinkput (duplicated) releasesock(sk)

So here add sock lock protection in smclistenwork() path, making it exclusive with other connection operations.

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

bnxten: Fix aggregation ID mask to prevent oops on 5760X chips

The 5760X (P7) chip's HW GRO/LRO interface is very similar to that of the previous generation (5750X or P5). However, the aggregation ID fields in the completion structures on P7 have been redefined from 16 bits to 12 bits. The freed up 4 bits are redefined for part of the metadata such as the VLAN ID. The aggregation ID mask was not modified when adding support for P7 chips. Including the extra 4 bits for the aggregation ID can potentially cause the driver to store or fetch the packet header of GRO/LRO packets in the wrong TPA buffer. It may hit the BUG() condition in skbpull() because the SKB contains no valid packet header:

kernel BUG at include/linux/skbuff.h:2766! Oops: invalid opcode: 0000 1 PREEMPT SMP NOPTI CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Kdump: loaded Tainted: G OE 6.12.0-rc2+ #7 Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: Dell Inc. PowerEdge R760/0VRV9X, BIOS 1.0.1 12/27/2022 RIP: 0010:ethtypetrans+0xda/0x140 Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 d0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48 RSP: 0018:ff615003803fcc28 EFLAGS: 00010283 RAX: 00000000000022d2 RBX: 0000000000000003 RCX: ff2e8c25da334040 RDX: 0000000000000040 RSI: ff2e8c25c1ce8000 RDI: ff2e8c25869f9000 RBP: ff2e8c258c31c000 R08: ff2e8c25da334000 R09: 0000000000000001 R10: ff2e8c25da3342c0 R11: ff2e8c25c1ce89c0 R12: ff2e8c258e0990b0 R13: ff2e8c25bb120000 R14: ff2e8c25c1ce89c0 R15: ff2e8c25869f9000 FS: 0000000000000000(0000) GS:ff2e8c34be300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f05317e4c8 CR3: 000000108bac6006 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? die+0x33/0x90 ? dotrap+0xd9/0x100 ? ethtypetrans+0xda/0x140 ? doerrortrap+0x65/0x80 ? ethtypetrans+0xda/0x140 ? excinvalidop+0x4e/0x70 ? ethtypetrans+0xda/0x140 ? asmexcinvalidop+0x16/0x20 ? ethtypetrans+0xda/0x140 bnxttpaend+0x10b/0x6b0 [bnxten] ? bnxttpastart+0x195/0x320 [bnxten] bnxtrxpkt+0x902/0xd90 [bnxten] ? bnxttxint.constprop.0+0x89/0x300 [bnxten] ? kmemcachefree+0x343/0x440 ? bnxttxint.constprop.0+0x24f/0x300 [bnxten] bnxtpollwork+0x193/0x370 [bnxten] bnxtpollp5+0x9a/0x300 [bnxten] ? trytowakeup+0x209/0x670 napipoll+0x29/0x1b0

Fix it by redefining the aggregation ID mask for P5PLUS chips to be 12 bits. This will work because the maximum aggregation ID is less than 4096 on all P5PLUS chips.

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

net/smc: protect link down work from execute after lgr freed

link down work may be scheduled before lgr freed but execute after lgr freed, which may result in crash. So it is need to hold a reference before shedule link down work, and put the reference after work executed or canceled.

The relevant crash call stack as follows: listdel corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smclinkdownwork [smc] RIP: 0010:listdelentryvalid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsemdownwriteslowpath+0x17e/0x470 smclinkdownwork+0x3c/0x60 [smc] processonework+0x1ac/0x350 workerthread+0x49/0x2f0 ? rescuerthread+0x360/0x360 kthread+0x118/0x140 ? kthreadbindmask+0x60/0x60 retfromfork+0x1f/0x30

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

RDMA/bnxtre: Fix max SGEs for the Work Request

Gen P7 supports up to 13 SGEs for now. WQE software structure can hold only 6 now. Since the max send sge is reported as 13, the stack can give requests up to 13 SGEs. This is causing traffic failures and system crashes.

Use the define for max SGE supported for variable size. This will work for both static and variable WQEs.

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

smb: client: fix double free of TCPServerInfo::hostname

When shutting down the server in cifsputtcpsession(), cifsd thread might be reconnecting to multiple DFS targets before it realizes it should exit the loop, so @server->hostname can't be freed as long as cifsd thread isn't done. Otherwise the following can happen:

RIP: 0010:slabfree+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: <TASK> ? showtraceloglvl+0x1c4/0x2df ? showtraceloglvl+0x1c4/0x2df ? reconnecttargetunlocked+0x3e/0x160 [cifs] ? diebody.cold+0x8/0xd ? die+0x2b/0x50 ? dotrap+0xce/0x120 ? slabfree+0x223/0x3c0 ? doerrortrap+0x65/0x80 ? slabfree+0x223/0x3c0 ? excinvalidop+0x4e/0x70 ? slabfree+0x223/0x3c0 ? asmexcinvalidop+0x16/0x20 ? slabfree+0x223/0x3c0 ? extracthostname+0x5c/0xa0 [cifs] ? extracthostname+0x5c/0xa0 [cifs] ? kmalloc+0x4b/0x140 reconnecttargetunlocked+0x3e/0x160 [cifs] reconnectdfsserver+0x145/0x430 [cifs] cifshandlestandard+0x1ad/0x1d0 [cifs] cifsdemultiplexthread+0x592/0x730 [cifs] ? pfxcifsdemultiplexthread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x29/0x50 </TASK>

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

ksmbd: fix racy issue from session lookup and expire

Increment the session reference count within the lock for lookup to avoid racy issue with session expire.

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

virt: tdx-guest: Just leak decrypted memory on unrecoverable errors

In CoCo VMs it is possible for the untrusted host to cause setmemorydecrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.

Leak the decrypted memory when setmemorydecrypted() fails, and don't need to print an error since setmemorydecrypted() will call WARNONCE().

Bluetooth: btmtk: avoid UAF in btmtkprocesscoredump

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

iommu/vt-d: Remove cache tags before disabling ATS

The current implementation removes cache tags after disabling ATS, leading to potential memory leaks and kernel crashes. Specifically, CACHETAGDEVTLB type cache tags may still remain in the list even after the domain is freed, causing a use-after-free condition.

This issue really shows up when multiple VFs from different PFs passed through to a single user-space process via vfio-pci. In such cases, the kernel may crash with kernel messages like:

BUG: kernel NULL pointer dereference, address: 0000000000000014 PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 74 UID: 0 PID: 3183 Comm: testCli Not tainted 6.11.9 #2 RIP: 0010:cachetagflushrange+0x9b/0x250 Call Trace: <TASK> ? die+0x1f/0x60 ? pagefaultoops+0x163/0x590 ? excpagefault+0x72/0x190 ? asmexcpagefault+0x22/0x30 ? cachetagflushrange+0x9b/0x250 ? cachetagflushrange+0x5d/0x250 inteliommutlbsync+0x29/0x40 inteliommuunmappages+0xfe/0x160 iommuunmap+0xd8/0x1a0 vfiounmapunpin+0x182/0x340 [vfioiommutype1] vfioremovedma+0x2a/0xb0 [vfioiommutype1] vfioiommutype1ioctl+0xafa/0x18e0 [vfioiommutype1]

Move cachetagunassigndomain() before iommudisablepcicaps() to fix it.

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

net/smc: check v2extoffset/eidcnt/ismgidcnt when receiving proposal msg

When receiving proposal msg in server, the fields v2extoffset/ eidcnt/ismgidcnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2extoffset, once exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks the fields v2extoffset/eidcnt/ismgidcnt before using them.

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

net/smc: check ipareaoffset and ipv6prefixescnt when receiving proposal msg

When receiving proposal msg in server, the field ipareaoffset and the field ipv6prefixescnt in proposal msg are from the remote client and can not be fully trusted. Especially the field ipareaoffset, once exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks ipareaoffset and ipv6prefixescnt before using them.

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

net/smc: check return value of sockrecvmsg when draining clc data

When receiving clc msg, the field length in smcclcmsghdr indicates the length of msg should be received from network and the value should not be fully trusted as it is from the network. Once the value of length exceeds the value of buflen in function smcclcwaitmsg it may run into deadloop when trying to drain the remaining data exceeding buflen.

This patch checks the return value of sockrecvmsg when draining data in case of deadloop in draining.

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

RDMA/rtrs: Ensure 'ibsge list' is accessible

Move the declaration of the 'ibsge list' variable outside the 'alwaysinvalidate' block to ensure it remains accessible for use throughout the function.

Previously, 'ibsge list' was declared within the 'alwaysinvalidate' block, limiting its accessibility, then caused a 'BUG: kernel NULL pointer dereference'[1]. ? diebody.cold+0x19/0x27 ? pagefaultoops+0x15a/0x2d0 ? searchmoduleextables+0x19/0x60 ? searchbpfextables+0x5f/0x80 ? excpagefault+0x7e/0x180 ? asmexcpagefault+0x26/0x30 ? memcpyorig+0xd5/0x140 rxemrcopy+0x1c3/0x200 [rdmarxe] ? rxepoolgetindex+0x4b/0x80 [rdmarxe] copydata+0xa5/0x230 [rdmarxe] rxerequester+0xd9b/0xf70 [rdmarxe] ? finishtaskswitch.isra.0+0x99/0x2e0 rxesender+0x13/0x40 [rdmarxe] dotask+0x68/0x1e0 [rdmarxe] processonework+0x177/0x330 workerthread+0x252/0x390 ? pfxworkerthread+0x10/0x10

This change ensures the variable is available for subsequent operations that require it.

[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/

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

can: j1939: j1939sessionnew(): fix skb reference counting

Since j1939sessionskbqueue() does an extra skbget() for each new skb, do the same for the initial one in j1939sessionnew() to avoid refcount underflow.

[mkl: clean up commit message]

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

net: renesas: rswitch: avoid use-after-put for a device tree node

The device tree node saved in the rswitchdevice structure is used at several driver locations. So passing this node to ofnodeput() after the first use is wrong.

Move ofnodeput() for this node to exit paths.

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

net/smc: check smcdv2extoffset when receiving proposal msg

When receiving proposal msg in server, the field smcdv2extoffset in proposal msg is from the remote client and can not be fully trusted. Once the value of smcdv2extoffset exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks the value of smcdv2extoffset before using it.

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

net: fix memory leak in tcpconnrequest()

If inetcskreqskqueuehashadd() return false, tcpconnrequest() will return without free the dst memory, which allocated in afops->routereq.

Here is the kmemleak stack:

unreferenced object 0xffff8881198631c0 (size 240): comm "softirq", pid 0, jiffies 4299266571 (age 1802.392s) hex dump (first 32 bytes): 00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ................ 81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00 .U.............. backtrace: [<ffffffffb93e8d4c>] kmemcachealloc+0x60c/0xa80 [<ffffffffba11b4c5>] dstalloc+0x55/0x250 [<ffffffffba227bf6>] rtdstalloc+0x46/0x1d0 [<ffffffffba23050a>] mkrouteoutput+0x29a/0xa50 [<ffffffffba23456b>] iprouteoutputkeyhash+0x10b/0x240 [<ffffffffba2346bd>] iprouteoutputflow+0x1d/0x90 [<ffffffffba254855>] inetcskroutereq+0x2c5/0x500 [<ffffffffba26b331>] tcpconnrequest+0x691/0x12c0 [<ffffffffba27bd08>] tcprcvstateprocess+0x3c8/0x11b0 [<ffffffffba2965c6>] tcpv4dorcv+0x156/0x3b0 [<ffffffffba299c98>] tcpv4rcv+0x1cf8/0x1d80 [<ffffffffba239656>] ipprotocoldeliverrcu+0xf6/0x360 [<ffffffffba2399a6>] iplocaldeliverfinish+0xe6/0x1e0 [<ffffffffba239b8e>] iplocaldeliver+0xee/0x360 [<ffffffffba239ead>] iprcv+0xad/0x2f0 [<ffffffffba110943>] netifreceiveskbonecore+0x123/0x140

Call dstrelease() to free the dst memory when inetcskreqskqueuehashadd() return false in tcpconnrequest().

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

netdev: prevent accessing NAPI instances from another namespace

The NAPI IDs were not fully exposed to user space prior to the netlink API, so they were never namespaced. The netlink API must ensure that at the very least NAPI instance belongs to the same netns as the owner of the genl sock.

napibyid() can become static now, but it needs to move because of devgetbynapiid().

btrfs: fix use-after-free in btrfsencodedreadendio()

btrfs: ref-verify: fix use-after-free after invalid ref action

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

scsi: qla2xxx: Fix use after free on unload

System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpcthread to terminate (UNLOADING flag and kthreadstop).

On setting the UNLOADING flag when dpcthread happens to run at the time and sees the flag, this causes dpcthread to exit and clean up itself. When kthreadstop is called for final cleanup, this causes use after free.

Remove UNLOADING signal to terminate dpcthread. Use the kthreadstop as the main signal to exit dpcthread.

[596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x8664 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:slabfree+0x17d/0x360

... [596663.813008] Call Trace: [596663.813022] ? dentrykill+0x121/0x170 [596663.813030] ? condresched+0x15/0x30 [596663.813034] ? condresched+0x15/0x30 [596663.813039] ? waitforcompletion+0x35/0x190 [596663.813048] ? trytowakeup+0x63/0x540 [596663.813055] freetask+0x5a/0x60 [596663.813061] kthreadstop+0xf3/0x100 [596663.813103] qla2x00removeone+0x284/0x440 [qla2xxx]

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

LoongArch: Add architecture specific hugepteclear()

When executing mm selftests runvmtests.sh, there is such an error:

BUG: Bad page state in process uffd-unit-tests pfn:00000 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0 flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff) raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGEFLAGSCHECKATFREE flag(s) set Modules linked in: sndseqdummy sndseq sndseqdevice rfkill vfat fat virtioballoon efipstore virtionet pstore netfailover failover fuse nfnetlink virtioscsi virtiogpu virtiodmabuf dmmultipath efivarfs CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001 0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000 0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940 0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000 0000000000000000 90000000028f8940 ffff800000000000 0000000000000000 0000000000000000 0000000000000000 9000000000223a94 000000012001839c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000000223a94>] showstack+0x5c/0x180 [<9000000001c3fd64>] dumpstacklvl+0x6c/0xa0 [<900000000056aa08>] badpage+0x1a0/0x1f0 [<9000000000574978>] freeunreffolios+0xbf0/0xd20 [<90000000004e65cc>] foliosputrefs+0x1a4/0x2b8 [<9000000000599a0c>] freepagesandswapcache+0x164/0x260 [<9000000000547698>] tlbbatchpagesflush+0xa8/0x1c0 [<9000000000547f30>] tlbfinishmmu+0xa8/0x218 [<9000000000543cb8>] exitmmap+0x1a0/0x360 [<9000000000247658>] mmput+0x78/0x200 [<900000000025583c>] doexit+0x43c/0xde8 [<9000000000256490>] dogroupexit+0x68/0x110 [<9000000000256554>] sysexitgroup+0x1c/0x20 [<9000000001c413b4>] dosyscall+0x94/0x130 [<90000000002216d8>] handlesyscall+0xb8/0x158 Disabling lock debugging due to kernel taint BUG: non-zero pgtablesbytes on freeing mm: -16384

On LoongArch system, invalid huge pte entry should be invalidptetable or a single PAGEHUGE bit rather than a zero value. And it should be the same with invalid pmd entry, since pmdnone() is called by function freepgdrange() and pmdnone() return 0 by hugepteclear(). So single PAGEHUGE bit is also treated as a valid pte table and freepterange() will be called in freepmdrange().

freepmdrange() pmd = pmdoffset(pud, addr); do { next = pmdaddrend(addr, end); if (pmdnoneorclearbad(pmd)) continue; freepterange(tlb, pmd, addr); } while (pmd++, addr = next, addr != end);

Here invalidptetable is used for both invalid huge pte entry and pmd entry.

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

iommufd: Fix outfput in iommufdfaultalloc()

As fput() calls the file->fop->release op, where fault obj and ictx are getting released, there is no need to release these two after fput() one more time, which would result in imbalanced refcounts: refcountt: decrement hit 0; leaking memory. WARNING: CPU: 48 PID: 2369 at lib/refcount.c:31 refcountwarnsaturate+0x60/0x230 Call trace: refcountwarnsaturate+0x60/0x230 (P) refcountwarnsaturate+0x60/0x230 (L) iommufdfaultfopsrelease+0x9c/0xe0 [iommufd] ... VFS: Close: file count is 0 (fop=iommufdfops [iommufd]) WARNING: CPU: 48 PID: 2369 at fs/open.c:1507 filpflush+0x3c/0xf0 Call trace: filpflush+0x3c/0xf0 (P) filpflush+0x3c/0xf0 (L) arm64sysclose+0x34/0x98 ... imbalanced put on file reference count WARNING: CPU: 48 PID: 2369 at fs/file.c:74 filerefput+0x100/0x138 Call trace: filerefput+0x100/0x138 (P) filerefput+0x100/0x138 (L) fputsync+0x4c/0xd0

Drop those two lines to fix the warnings above.

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

xsk: fix OOB map writes when deleting elements

Jordy says:

" In the xskmapdeleteelem function an unsigned integer (map->maxentries) is compared with a user-controlled signed integer (k). Due to implicit type conversion, a large unsigned value for map->maxentries can bypass the intended bounds check:

if (k >= map->maxentries) return -EINVAL;

This allows k to hold a negative value (between -2147483648 and -2), which is then used as an array index in m->xskmap[k], which results in an out-of-bounds access.

spinlockbh(&m->lock); mapentry = &m->xskmap[k]; // Out-of-bounds mapentry oldxs = unrcupointer(xchg(mapentry, NULL)); // Oob write if (oldxs) xskmapsockdelete(oldxs, mapentry); spinunlockbh(&m->lock);

The xchg operation can then be used to cause an out-of-bounds write. Moreover, the invalid mapentry passed to xskmapsockdelete can lead to further memory corruption. "

It indeed results in following splat:

[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108 [76612.904330] #PF: supervisor write access in kernel mode [76612.909639] #PF: errorcode(0x0002) - not-present page [76612.914855] PGD 0 P4D 0 [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470 [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [76612.939781] RIP: 0010:xskmapdeleteelem+0x2d/0x60 [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31 [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246 [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000 [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000 [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007 [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8 [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0 [76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000 [76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0 [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [76613.041086] PKRU: 55555554 [76613.043842] Call Trace: [76613.046331] <TASK> [76613.048468] ? die+0x20/0x60 [76613.051581] ? pagefaultoops+0x15a/0x450 [76613.055747] ? searchextable+0x22/0x30 [76613.059649] ? searchbpfextables+0x5f/0x80 [76613.063988] ? excpagefault+0xa9/0x140 [76613.067975] ? asmexcpagefault+0x22/0x30 [76613.072229] ? xskmapdeleteelem+0x2d/0x60 [76613.076573] ? xskmapdeleteelem+0x23/0x60 [76613.080914] sysbpf+0x19b7/0x23c0 [76613.084555] x64sysbpf+0x1a/0x20 [76613.088194] dosyscall64+0x37/0xb0 [76613.091832] entrySYSCALL64afterhwframe+0x4b/0x53 [76613.096962] RIP: 0033:0x7f80b6d1e88d [76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIGRAX: 0000000000000141 [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d [76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003 [76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000 [76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8 [76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00 ---truncated---

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

tcpbpf: Fix the skmemuncharge logic in tcpbpfsendmsg

The current sk memory accounting logic in SKREDIRECT is pre-uncharging tosend bytes, which is either msg->sg.size or a smaller value applybytes.

Potential problems with this strategy are as follows:

- If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.

- When tosend is set to applybytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - applybytes) bytes.

[...] 415 tosend = msg->sg.size; 416 if (psock->applybytes && psock->applybytes < tosend) 417 tosend = psock->applybytes; [...] 443 skmsgreturn(sk, msg, tosend); 444 releasesock(sk); 446 origsize = msg->sg.size; 447 ret = tcpbpfsendmsgredir(skredir, rediringress, 448 msg, tosend, flags); 449 sent = origsize - msg->sg.size; [...] 454 locksock(sk); 455 if (unlikely(ret < 0)) { 456 int free = skmsgfreenocharge(sk, msg); 458 if (!cork) 459 copied -= free; 460 } [...] 487 if (eval == SKREDIRECT) 488 skmemcharge(sk, tosend - sent); [...]

When running the selftest testtxmsgredirwaitsndmem with txmsgapply, the following warning will be reported:

------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/afinet.c:156 inetsockdestruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events skpsockdestroy RIP: 0010:inetsockdestruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn+0x89/0x130 ? inetsockdestruct+0x190/0x1a0 ? reportbug+0xfc/0x1e0 ? handlebug+0x5c/0xa0 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x190/0x1a0 skdestruct+0x25/0x220 skpsockdestroy+0x2b2/0x310 processscheduledworks+0xa3/0x3e0 workerthread+0x117/0x240 ? pfxworkerthread+0x10/0x10 kthread+0xcf/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x31/0x40 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---

In SKREDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret < 0), we shall invoke skmsgfree.

Same thing happens in case SKDROP, when tosend is set to applybytes, we may miss uncharging (msg->sg.size - applybytes) bytes. The same warning will be reported in selftest.

[...] 468 case SKDROP: 469 default: 470 skmsgfreepartial(sk, msg, tosend); 471 skmsgapplybytes(psock, tosend); 472 copied -= (tosend + delta); 473 return -EACCES; [...]

So instead of skmsgfreepartial we can do skmsgfree here.

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

netfilter: nftinner: incorrect percpu area handling under softirq

Softirq can interrupt ongoing packet from process context that is walking over the percpu area that contains inner header offsets.

Disable bh and perform three checks before restoring the percpu inner header offsets to validate that the percpu area is valid for this skbuff:

1) If the NFTPKTINFOINNERFULL flag is set on, then this skbuff has already been parsed before for inner header fetching to register.

2) Validate that the percpu area refers to this skbuff using the skbuff pointer as a cookie. If there is a cookie mismatch, then this skbuff needs to be parsed again.

3) Finally, validate if the percpu area refers to this tunnel type.

Only after these three checks the percpu area is restored to a on-stack copy and bh is enabled again.

After inner header fetching, the on-stack copy is stored back to the percpu area.

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

net: avoid potential UAF in defaultoperstate()

syzbot reported an UAF in defaultoperstate() [1]

Issue is a race between device and netns dismantles.

After calling rtnlunlock() from netdevruntodo(), we can not assume the netns of each device is still alive.

Make sure the device is not in NETREGUNREGISTERED state, and add an ASSERTRTNL() before the call to devgetbyindex().

We might move this ASSERTRTNL() in devgetbyindex() in the future.

[1]

BUG: KASAN: slab-use-after-free in devgetbyindex+0x5d/0x110 net/core/dev.c:852 Read of size 8 at addr ffff888043eba1b0 by task syz.0.0/5339

CPU: 0 UID: 0 PID: 5339 Comm: syz.0.0 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 devgetbyindex+0x5d/0x110 net/core/dev.c:852 defaultoperstate net/core/linkwatch.c:51 [inline] rfc2863policy+0x224/0x300 net/core/linkwatch.c:67 linkwatchdodev+0x3e/0x170 net/core/linkwatch.c:170 netdevruntodo+0x461/0x1000 net/core/dev.c:10894 rtnlunlock net/core/rtnetlink.c:152 [inline] rtnlnetunlock include/linux/rtnetlink.h:133 [inline] rtnldellink+0x760/0x8d0 net/core/rtnetlink.c:3520 rtnetlinkrcvmsg+0x791/0xcf0 net/core/rtnetlink.c:6911 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2541 netlinkunicastkernel net/netlink/afnetlink.c:1321 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1347 netlinksendmsg+0x8e4/0xcb0 net/netlink/afnetlink.c:1891 socksendmsgnosec net/socket.c:711 [inline] socksendmsg+0x221/0x270 net/socket.c:726 syssendmsg+0x52a/0x7e0 net/socket.c:2583 syssendmsg net/socket.c:2637 [inline] syssendmsg+0x269/0x350 net/socket.c:2669 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f2a3cb80809 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f2a3d9cd058 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f2a3cd45fa0 RCX: 00007f2a3cb80809 RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000008 RBP: 00007f2a3cbf393e R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f2a3cd45fa0 R15: 00007ffd03bc65c8 </TASK>

Allocated by task 5339: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] kasankmalloc+0x98/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] kmalloccachenoprof+0x243/0x390 mm/slub.c:4314 kmallocnoprof include/linux/slab.h:901 [inline] kmallocarraynoprof include/linux/slab.h:945 [inline] netdevcreatehash net/core/dev.c:11870 [inline] netdevinit+0x10c/0x250 net/core/dev.c:11890 opsinit+0x31e/0x590 net/core/netnamespace.c:138 setupnet+0x287/0x9e0 net/core/netnamespace.c:362 copynetns+0x33f/0x570 net/core/netnamespace.c:500 createnewnamespaces+0x425/0x7b0 kernel/nsproxy.c:110 unsharensproxynamespaces+0x124/0x180 kernel/nsproxy.c:228 ksysunshare+0x57d/0xa70 kernel/fork.c:3314 dosysunshare kernel/fork.c:3385 [inline] sesysunshare kernel/fork.c:3383 [inline] x64sysunshare+0x38/0x40 kernel/fork.c:3383 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x8 ---truncated---

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

netfilter: nftables: do not defer rule destruction via callrcu

nftableschaindestroy can sleep, it can't be used from callrcu callbacks.

Moreover, nftablesrulerelease() is only safe for error unwinding, while transaction mutex is held and the to-be-desroyed rule was not exposed to either dataplane or dumps, as it deactives+frees without the required synchronizercu() in-between.

nftruleexprdeactivate() callbacks will change ->use counters of other chains/sets, see e.g. nftlookup .deactivate callback, these must be serialized via transaction mutex.

Also add a few lockdep asserts to make this more explicit.

Calling synchronizercu() isn't ideal, but fixing this without is hard and way more intrusive. As-is, we can get:

WARNING: .. net/netfilter/nftablesapi.c:5515 nftsetdestroy+0x.. Workqueue: events nftablestransdestroywork RIP: 0010:nftsetdestroy+0x3fe/0x5c0 Call Trace: <TASK> nftablestransdestroywork+0x6b7/0xad0 processonework+0x64a/0xce0 workerthread+0x613/0x10d0

In case the synchronizercu becomes an issue, we can explore alternatives.

One way would be to allocate nfttransrule objects + one nfttranschain object, deactivate the rules + the chain and then defer the freeing to the nft destroy workqueue. We'd still need to keep the synchronizercu path as a fallback to handle -ENOMEM corner cases though.

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

drm/xe/regsr: Remove register pool

That pool implementation doesn't really work: if the krealloc happens to move the memory and return another address, the entries in the xarray become invalid, leading to use-after-free later:

BUG: KASAN: slab-use-after-free in xeregsrapplymmio+0x570/0x760 [xe] Read of size 4 at addr ffff8881244b2590 by task modprobe/2753

Allocated by task 2753: kasansavestack+0x39/0x70 kasansavetrack+0x14/0x40 kasansaveallocinfo+0x37/0x60 kasankmalloc+0xc3/0xd0 kmallocnodetrackcallernoprof+0x200/0x6d0 kreallocnoprof+0x229/0x380

Simplify the code to fix the bug. A better pooling strategy may be added back later if needed.

(cherry picked from commit e5283bd4dfecbd3335f43b62a68e24dae23f59e4)