In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix TSO DMA API usage causing oops
Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") moved the assignment of txskbuffdma[]'s members to be later in stmmactsoxmit().
The buf (dma cookie) and len stored in this structure are passed to dmaunmapsingle() by stmmactxclean(). The DMA API requires that the dma cookie passed to dmaunmapsingle() is the same as the value returned from dmamapsingle(). However, by moving the assignment later, this is not the case when priv->dmacap.addr64 > 32 as "des" is offset by protohdrlen.
This causes problems such as:
dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed
and with DMAAPIDEBUG enabled:
DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]
Fix this by maintaining "des" as the original DMA cookie, and use tsodes to pass the offset DMA cookie to stmmactsoallocator().
Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/
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:
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:
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:
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/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:
mptcp: fix TCP options overflow.
Syzbot reported the following splat:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 UID: 0 PID: 5836 Comm: sshd Not tainted 6.13.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:compoundhead include/linux/page-flags.h:242 [inline] RIP: 0010:putpage+0x23/0x260 include/linux/mm.h:1552 Code: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 <80> 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83 RSP: 0000:ffffc90003916c90 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000008 RCX: ffff888030458000 RDX: 0000000000000100 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac R10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007 R13: ffff88802a20a542 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbpageunref include/linux/skbuffref.h:43 [inline] skbfragunref include/linux/skbuffref.h:56 [inline] skbreleasedata+0x483/0x8a0 net/core/skbuff.c:1119 skbreleaseall net/core/skbuff.c:1190 [inline] kfreeskb+0x55/0x70 net/core/skbuff.c:1204 tcpcleanrtxqueue net/ipv4/tcpinput.c:3436 [inline] tcpack+0x2442/0x6bc0 net/ipv4/tcpinput.c:4032 tcprcvstateprocess+0x8eb/0x44e0 net/ipv4/tcpinput.c:6805 tcpv4dorcv+0x77d/0xc70 net/ipv4/tcpipv4.c:1939 tcpv4rcv+0x2dc0/0x37f0 net/ipv4/tcpipv4.c:2351 ipprotocoldeliverrcu+0x22e/0x440 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x341/0x5f0 net/ipv4/ipinput.c:233 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 netifreceiveskbonecore net/core/dev.c:5672 [inline] netifreceiveskb+0x2bf/0x650 net/core/dev.c:5785 processbacklog+0x662/0x15b0 net/core/dev.c:6117 napipoll+0xcb/0x490 net/core/dev.c:6883 napipoll net/core/dev.c:6952 [inline] netrxaction+0x89b/0x1240 net/core/dev.c:7074 handlesoftirqs+0x2d4/0x9b0 kernel/softirq.c:561 dosoftirq kernel/softirq.c:595 [inline] invokesoftirq kernel/softirq.c:435 [inline] irqexitrcu+0xf7/0x220 kernel/softirq.c:662 irqexitrcu+0x9/0x30 kernel/softirq.c:678 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimerinterrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049 asmsysvecapictimerinterrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0033:0x7f34f4519ad5 Code: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 <48> 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83 RSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246 RAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5 RDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0 RBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000 R10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4 R13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68 </TASK>
Eric noted a probable shinfo->nrfrags corruption, which indeed occurs.
The root cause is a buggy MPTCP option len computation in some circumstances: the ADDADDR option should be mutually exclusive with DSS since the blamed commit.
Still, mptcpestablishedoptionsaddaddr() tries to set the relevant info in mptcpoutoptions, if ---truncated---
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:
gve: guard XDP xmit NDO on existence of xdp queues
In GVE, dedicated XDP queues only exist when an XDP program is installed and the interface is up. As such, the NDO XDP XMIT callback should return early if either of these conditions are false.
In the case of no loaded XDP program, priv->numxdpqueues=0 which can cause a divide-by-zero error, and in the case of interface down, numxdpqueues remains untouched to persist XDP queue count for the next interface up, but the TX pointer itself would be NULL.
The XDP xmit callback also needs to synchronize with a device transitioning from open to close. This synchronization will happen via the GVEPRIVFLAGSNAPIENABLED bit along with a synchronizenet() call, which waits for any RCU critical sections at call-time to complete.
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:
netrom: check buffer length before accessing it
Syzkaller reports an uninit value read from ax25cmp when sending raw message through ieee802154 implementation.
===================================================== BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25addr.c:119 ax25cmp+0x3a5/0x460 net/ax25/ax25addr.c:119 nrdevget+0x20e/0x450 net/netrom/nrroute.c:601 nrrouteframe+0x1a2/0xfc0 net/netrom/nrroute.c:774 nrxmit+0x5a/0x1c0 net/netrom/nrdev.c:144 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] rawsendmsg+0x654/0xc10 net/ieee802154/socket.c:299 ieee802154socksendmsg+0x91/0xc0 net/ieee802154/socket.c:96 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5e9/0xb10 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 allocskb+0x318/0x740 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1286 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6334 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2780 sockallocsendskb include/net/sock.h:1884 [inline] rawsendmsg+0x36d/0xc10 net/ieee802154/socket.c:282 ieee802154socksendmsg+0x91/0xc0 net/ieee802154/socket.c:96 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 =====================================================
This issue occurs because the skb buffer is too small, and it's actual allocation is aligned. This hides an actual issue, which is that nrrouteframe does not validate the buffer size before using it.
Fix this issue by checking skb->len before accessing any fields in skb->data.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
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().
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:
ksmbd: fix Out-of-Bounds Write in ksmbdvfsstreamwrite
An offset from client could be a negative value, It could allows to write data outside the bounds of the allocated buffer. Note that this issue is coming when setting 'vfs objects = streamsxattr parameter' in ksmbd.conf.
can: hi311x: hi3110canist(): fix potential use-after-free
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: 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: reenable NETIFFIPV6CSUM offload for BIG TCP packets
The blamed commit disabled hardware offoad of IPv6 packets with extension headers on devices that advertise NETIFFIPV6CSUM, based on the definition of that feature in skbuff.h:
- %NETIFFIPV6CSUM - Driver (device) is only able to checksum plain TCP or UDP packets over IPv6. These are specifically unencapsulated packets of the form IPv6|TCP or IPv6|UDP where the Next Header field in the IPv6 header is either TCP or UDP. IPv6 extension headers are not supported with this feature. This feature cannot be set in features for a device with NETIFFHWCSUM also set. This feature is being DEPRECATED (see below).
The change causes skbwarnbadoffload to fire for BIG TCP packets.
[ 496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skbwarnbadoffload+0xc4/0xe0
[ 496.310297] ? skbwarnbadoffload+0xc4/0xe0 [ 496.310300] skbchecksumhelp+0x129/0x1f0 [ 496.310303] skbcsumhwoffloadhelp+0x150/0x1b0 [ 496.310306] validatexmitskb+0x159/0x270 [ 496.310309] validatexmitskblist+0x41/0x70 [ 496.310312] schdirectxmit+0x5c/0x250 [ 496.310317] qdiscrun+0x388/0x620
BIG TCP introduced an IPV6TLVJUMBO IPv6 extension header to communicate packet length, as this is an IPv6 jumbogram. But, the feature is only enabled on devices that support BIG TCP TSO. The header is only present for PFPACKET taps like tcpdump, and not transmitted by physical devices.
For this specific case of extension headers that are not transmitted, return to the situation before the blamed commit and support hardware offload.
ipv6hashopoptjumbo() tests not only whether this header is present, but also that it is the only extension header before a terminal (L4) header.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix Out-of-Bounds Read in ksmbdvfsstreamread
An offset from client could be a negative value, It could lead to an out-of-bounds read from the streambuf. Note that this issue is coming when setting 'vfs objects = streamsxattr parameter' in ksmbd.conf.
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().
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix ordering of qlen adjustment
Changes to sch->q.qlen around qdisctreereducebacklog() need to happen before a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.
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.