bus: mhi: ep: Update read pointer only after buffer is written

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

scsi: target: pscsi: Fix bioput() for error case

As of commit 066ff571011d ("block: turn biokmalloc into a simple kmalloc wrapper"), a bio allocated by biokmalloc() must be freed by biouninit() and kfree(). That is not done properly for the error case, hitting WARN and NULL pointer dereference in biofree().

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

nbd: fix race between timeout and normal completion

If request timetout is handled by nbdrequeuecmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered.

Fix the race by clearing NBDCMDINFLIGHT in nbdrequeuecmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.

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

nfsd: don't replace page in rqpages if it's a continuation of last page

The splice read calls nfsdspliceactor to put the pages containing file data into the svcrqst->rqpages array. It's possible however to get a splice result that only has a partial page at the end, if (e.g.) the filesystem hands back a short read that doesn't cover the whole page.

nfsdspliceactor will plop the partial page into its rqpages array and return. Then later, when nfsdspliceactor is called again, the remainder of the page may end up being filled out. At this point, nfsdspliceactor will put the page into the array again corrupting the reply. If this is done enough times, rqnextpage will overrun the array and corrupt the trailing fields -- the rqrespages and rqnextpage pointers themselves.

If we've already added the page to the array in the last pass, don't add it to the array a second time when dealing with a splice continuation. This was originally handled properly in nfsdspliceactor, but commit 91e23b1c3982 ("NFSD: Clean up nfsdspliceactor()") removed the check for it.

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

bnxt: properly flush XDP redirect lists

We encountered following crash when testing a XDPREDIRECT feature in production:

[56251.579676] listadd corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd 40f30). [56251.601413] ------------[ cut here ]------------ [56251.611357] kernel BUG at lib/listdebug.c:29! [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6. 3 #1 [56251.653155] Tainted: [P]=PROPRIETARYMODULE, [O]=OOTMODULE [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025 [56251.682626] RIP: 0010:listaddvalidorreport+0x4b/0xa0 [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89 [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246 [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000 [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80 [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18 [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000 [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40 [56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000 [56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0 [56251.831365] PKRU: 55555554 [56251.838653] Call Trace: [56251.845560] <IRQ> [56251.851943] cpumapenqueue.cold+0x5/0xa [56251.860243] xdpdoredirect+0x2d9/0x480 [56251.868388] bnxtrxxdp+0x1d8/0x4c0 [bnxten] [56251.877028] bnxtrxpkt+0x5f7/0x19b0 [bnxten] [56251.885665] ? cpumaxwrite+0x1e/0x100 [56251.893510] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.902276] bnxtpollwork+0x190/0x340 [bnxten] [56251.911058] bnxtpoll+0xab/0x1b0 [bnxten] [56251.919041] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.927568] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.935958] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.944250] napipoll+0x2b/0x160 [56251.951155] bpftrampoline6442548651+0x79/0x123 [56251.959262] napipoll+0x5/0x160 [56251.966037] netrxaction+0x3d2/0x880 [56251.973133] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.981265] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.989262] ? hrtimerrunqueues+0x162/0x2a0 [56251.996967] ? srsoaliasreturnthunk+0x5/0xfbef5 [56252.004875] ? srsoaliasreturnthunk+0x5/0xfbef5 [56252.012673] ? bnxtmsix+0x62/0x70 [bnxten] [56252.019903] handlesoftirqs+0xcf/0x270 [56252.026650] irqexitrcu+0x67/0x90 [56252.032933] commoninterrupt+0x85/0xa0 [56252.039498] </IRQ> [56252.044246] <TASK> [56252.048935] asmcommoninterrupt+0x26/0x40 [56252.055727] RIP: 0010:cpuidleenterstate+0xb8/0x420 [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29 [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202 [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000 [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000 [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860 [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000 [56252.146667] ? cpuidleenterstate+0xab/0x420 [56252.153909] cpuidleenter+0x2d/0x40 [56252.160360] doidle+0x176/0x1c0 [56252.166456 ---truncated---

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

serial: 8250dw: unregister 8250 port if clknotifierregister() fails

dw8250probe() registers the 8250 port via serial8250register8250port() and then, if the device has a clock, registers a clock notifier. If clknotifierregister() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250unregisterport() lives in dw8250remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved privatedata and serialin/serialout callbacks), so any access to that port slot before a rebind is a use-after-free hazard.

Unregister the port on the clknotifierregister() error path.

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

x86/sev: Evict cache lines during SNP memory validation

An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.

CPUID bit Fn8000001FEBX[31] defines the COHERENCYSFWNO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.

Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCYSFWNO bit is not set, indicating the SNP guest is vulnerable.

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

ice: Fix crash by keep old cfg when update TCs more than queues

There are problems if allocated queues less than Traffic Classes.

Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config for DCB") already disallow setting less queues than TCs.

Another case is if we first set less queues, and later update more TCs config due to LLDP, icevsicfgtc() will failed but left dirty numtxq/rxq and tccfg in vsi, that will cause invalid pointer access.

[ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated. [ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)! [ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0 [ 95.969621] general protection fault: 0000 [#1] SMP NOPTI [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1 [ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021 [ 95.969992] RIP: 0010:devmkmalloc+0xa/0x60 [ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206 [ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0 [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200 [ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000 [ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100 [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460 [ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000 [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0 [ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 95.971530] PKRU: 55555554 [ 95.971573] Call Trace: [ 95.971622] icesetuprxring+0x39/0x110 [ice] [ 95.971695] icevsisetuprxrings+0x54/0x90 [ice] [ 95.971774] icevsiopen+0x25/0x120 [ice] [ 95.971843] iceopeninternal+0xb8/0x1f0 [ice] [ 95.971919] iceenavsi+0x4f/0xd0 [ice] [ 95.971987] icedcbenadisvsi.constprop.5+0x29/0x90 [ice] [ 95.972082] icepfdcbcfg+0x29a/0x380 [ice] [ 95.972154] icedcbnlsetets+0x174/0x1b0 [ice] [ 95.972220] dcbnlieeeset+0x89/0x230 [ 95.972279] ? dcbnlieeedel+0x150/0x150 [ 95.972341] dcbdoit+0x124/0x1b0 [ 95.972392] rtnetlinkrcvmsg+0x243/0x2f0 [ 95.972457] ? dcbdoit+0x14d/0x1b0 [ 95.972510] ? kmallocnodetrackcaller+0x1d3/0x280 [ 95.972591] ? rtnlcalcit.isra.31+0x100/0x100 [ 95.972661] netlinkrcvskb+0xcf/0xf0 [ 95.972720] netlinkunicast+0x16d/0x220 [ 95.972781] netlinksendmsg+0x2ba/0x3a0 [ 95.975891] socksendmsg+0x4c/0x50 [ 95.979032] syssendmsg+0x2e4/0x300 [ 95.982147] ? kmemcachealloc+0x13e/0x190 [ 95.985242] ? wakeupcommonlock+0x79/0x90 [ 95.988338] ? checkobjectsize+0xac/0x1b0 [ 95.991440] ? copytouser+0x22/0x30 [ 95.994539] ? moveaddrtouser+0xbb/0xd0 [ 95.997619] ? syssendmsg+0x53/0x80 [ 96.000664] syssendmsg+0x53/0x80 [ 96.003747] dosyscall64+0x5b/0x1d0 [ 96.006862] entrySYSCALL64afterhwframe+0x65/0xca

Only update numtxq/rxq when passed check, and restore tccfg if setup queue map failed.

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

i40e: Fix macvlan leak by synchronizing access to macfilterhash

This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->macfilterhash. The leak occurs when multiple threads attempt to modify the macfilterhash simultaneously, leading to inconsistent state and potential memory leaks.

To fix this, we now wrap the calls to i40edelmacfilter() and zeroing vf->defaultlanaddr.addr with spinlock/unlockbh(&vsi->macfilterhashlock), ensuring atomic operations and preventing concurrent access.

Additionally, we add lockdepassertheld(&vsi->macfilterhashlock) in i40eaddmacfilter() to help catch similar issues in the future.

Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting portvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the macfilterhash.

This synchronization ensures the integrity of the macfilterhash and prevents the described leak.

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

scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts

Ensure SRB is returned during I/O timeout error escalation. If that is not possible fail the escalation path.

Following crash stack was seen:

BUG: unable to handle kernel paging request at 0000002f56aa90f8 IP: qlachkedifrxsadeletepending+0x14/0x30 [qla2xxx] Call Trace: ? qla2x00statusentry+0x19f/0x1c50 [qla2xxx] ? qla2x00startsp+0x116/0x1170 [qla2xxx] ? dmapoolalloc+0x1d6/0x210 ? mempoolalloc+0x54/0x130 ? qla24xxprocessresponsequeue+0x548/0x12b0 [qla2xxx] ? qladowork+0x2d/0x40 [qla2xxx] ? processonework+0x14c/0x390

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

wifi: iwlwifi: mvm: fix double listadd at iwlmvmmacwaketxqueue

After successfull station association, if station queues are disabled for some reason, the related lists are not emptied. So if some new element is added to the list in iwlmvmmacwaketxqueue, it can match with the old one and produce a BUG like this:

[ 46.535263] listadd corruption. prev->next should be next (ffff94c1c318a360), but was 0000000000000000. (prev=ffff94c1d02d3388). [ 46.535283] ------------[ cut here ]------------ [ 46.535284] kernel BUG at lib/listdebug.c:26! [ 46.535290] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 46.585304] CPU: 0 PID: 623 Comm: wpasupplicant Not tainted 5.19.0-rc3+ #1 [ 46.592380] Hardware name: Dell Inc. Inspiron 660s/0478VN , BIOS A07 08/24/2012 [ 46.600336] RIP: 0010:listaddvalid.cold+0x3d/0x3f [ 46.605475] Code: f2 4c 89 c1 48 89 fe 48 c7 c7 c8 40 67 93 e8 20 cc fd ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 70 40 67 93 e8 09 cc fd ff <0f> 0b 48 89 fe 48 c7 c7 00 41 67 93 e8 f8 cb fd ff 0f 0b 48 89 d1 [ 46.624469] RSP: 0018:ffffb20800ab76d8 EFLAGS: 00010286 [ 46.629854] RAX: 0000000000000075 RBX: ffff94c1c318a0e0 RCX: 0000000000000000 [ 46.637105] RDX: 0000000000000201 RSI: ffffffff9365e100 RDI: 00000000ffffffff [ 46.644356] RBP: ffff94c1c5f43370 R08: 0000000000000075 R09: 3064316334396666 [ 46.651607] R10: 3364323064316334 R11: 39666666663d7665 R12: ffff94c1c5f43388 [ 46.658857] R13: ffff94c1d02d3388 R14: ffff94c1c318a360 R15: ffff94c1cf2289c0 [ 46.666108] FS: 00007f65634ff7c0(0000) GS:ffff94c1da200000(0000) knlGS:0000000000000000 [ 46.674331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.680170] CR2: 00007f7dfe984460 CR3: 000000010e894003 CR4: 00000000000606f0 [ 46.687422] Call Trace: [ 46.689906] <TASK> [ 46.691950] iwlmvmmacwaketxqueue+0xec/0x15c [iwlmvm] [ 46.697601] ieee80211queueskb+0x4b3/0x720 [mac80211] [ 46.702973] ? stainfoget+0x46/0x60 [mac80211] [ 46.707703] ieee80211tx+0xad/0x110 [mac80211] [ 46.712355] ieee80211txskbtidband+0x71/0x90 [mac80211] ...

In order to avoid this problem, we must also remove the related lists when station queues are disabled.

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

smb: client: prevent races in ->queryinterfaces()

It was possible for two query interface works to be concurrently trying to update the interfaces.

Prevent this by checking and updating ifacelastupdate under ifacelock.

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

net: wwan: t7xx: validate portcount against message length in t7xxportenummsghandler

t7xxportenummsghandler() uses the modem-supplied portcount field as a loop bound over portmsg->data[] without checking that the message buffer contains sufficient data. A modem sending portcount=65535 in a 12-byte buffer triggers a slab-out-of-bounds read of up to 262140 bytes.

Add a sizeof(portmsg) check before accessing the port message header fields to guard against undersized messages.

Add a structsize() check after extracting portcount and before the loop.

In t7xxparsehostrtdata(), guard the rtfeature header read with a remaining-buffer check before accessing datalen, validate featdatalen against the actual remaining buffer to prevent OOB reads and signed integer overflow on offset.

Pass msglen from both call sites: skb->len at the DPMAIF path after skbpull(), and the validated featdatalen at the handshake path.

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

scsi: sd: Fix off-by-one error in sdreadblockcharacteristics()

Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sdreadblockcharacteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.

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

ASoC: SOF: Add some bounds checking to firmware data

Smatch complains about "head->fullsize - head->headersize" can underflow. To some extent, we're always going to have to trust the firmware a bit. However, it's easy enough to add a check for negatives, and let's add a upper bounds check as well.

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

x86/tdx: Panic on bad configs that #VE on "private" memory access

All normal kernel memory is "TDX private memory". This includes everything from kernel stacks to kernel text. Handling exceptions on arbitrary accesses to kernel memory is essentially impossible because they can happen in horribly nasty places like kernel entry/exit. But, TDX hardware can theoretically deliver a virtualization exception (#VE) on any access to private memory.

But, it's not as bad as it sounds. TDX can be configured to never deliver these exceptions on private memory with a "TD attribute" called ATTRSEPTVEDISABLE. The guest has no way to set this attribute, but it can check it.

Ensure ATTRSEPTVEDISABLE is set in early boot. panic() if it is unset. There is no sane way for Linux to run with this attribute clear so a panic() is appropriate.

There's small window during boot before the check where kernel has an early #VE handler. But the handler is only for port I/O and will also panic() as soon as it sees any other #VE, such as a one generated by a private memory access.

[ dhansen: Rewrite changelog and rebase on new tdxparsetdinfo(). Add Kirill's tested-by because I made changes since he wrote this. ]

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

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

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

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

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

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

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

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

mptcp: make fallback action and fallback decision atomic

Syzkaller reported the following splat:

WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 checkfullyestablished net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:checkfullyestablished net/mptcp/options.c:982 [inline] RIP: 0010:mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: <IRQ> tcpreset+0x26f/0x2b0 net/ipv4/tcpinput.c:4432 tcpvalidateincoming+0x1057/0x1b60 net/ipv4/tcpinput.c:5975 tcprcvestablished+0x5b5/0x21f0 net/ipv4/tcpinput.c:6166 tcpv4dorcv+0x5dc/0xa70 net/ipv4/tcpipv4.c:1925 tcpv4rcv+0x3473/0x44a0 net/ipv4/tcpipv4.c:2363 ipprotocoldeliverrcu+0xba/0x480 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2f1/0x500 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iplocaldeliver+0x1be/0x560 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:469 [inline] iprcvfinish net/ipv4/ipinput.c:447 [inline] NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iprcv+0x514/0x810 net/ipv4/ipinput.c:567 netifreceiveskbonecore+0x197/0x1e0 net/core/dev.c:5975 netifreceiveskb+0x1f/0x120 net/core/dev.c:6088 processbacklog+0x301/0x1360 net/core/dev.c:6440 napipoll.constprop.0+0xba/0x550 net/core/dev.c:7453 napipoll net/core/dev.c:7517 [inline] netrxaction+0xb44/0x1010 net/core/dev.c:7644 handlesoftirqs+0x1d0/0x770 kernel/softirq.c:579 dosoftirq+0x3f/0x90 kernel/softirq.c:480 </IRQ> <TASK> localbhenableip+0xed/0x110 kernel/softirq.c:407 localbhenable include/linux/bottomhalf.h:33 [inline] inetcsklistenstop+0x2c5/0x1070 net/ipv4/inetconnectionsock.c:1524 mptcpchecklistenstop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcpchecklistenstop net/mptcp/mib.h:118 [inline] mptcpclose+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcpclose+0x2f/0x140 net/mptcp/protocol.c:3066 inetrelease+0xed/0x200 net/ipv4/afinet.c:435 inet6release+0x4f/0x70 net/ipv6/afinet6.c:487 sockrelease+0xb3/0x270 net/socket.c:649 sockclose+0x1c/0x30 net/socket.c:1439 fput+0x402/0xb70 fs/filetable.c:465 taskworkrun+0x150/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xd4 ---truncated---

An improper input validation flaw was found in the eBPF subsystem in the Linux kernel. The issue occurs due to a lack of proper validation of dynamic pointers within user-supplied eBPF programs prior to executing them. This may allow an attacker with CAPBPF privileges to escalate privileges and execute arbitrary code in the context of the kernel.

A flaw was found in the Linux kernel's udmabuf device driver, within a fault handler. This issue occurs due to the lack of proper validation of user-supplied data, which can result in memory access past the end of an array. This may allow an attacker to escalate privileges and execute arbitrary code in the context of the kernel.

A use-after-free flaw was found in route4change in the net/sched/clsroute.c filter implementation in the Linux kernel. This flaw allows a local user to crash the system and possibly lead to a local privilege escalation problem.

A use-after-free flaw was found in the Linux kernel’s Atheros wireless adapter driver in the way a user forces the ath9khtcwaitfortarget function to fail with some input messages. This flaw allows a local user to crash or potentially escalate their privileges on the system.

A use-after-free flaw was found in nftables cross-table in the net/netfilter/nftablesapi.c function in the Linux kernel. This flaw allows a local, privileged attacker to cause a use-after-free problem at the time of table deletion, possibly leading to local privilege escalation.

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

drm/i915/vma: Fix UAF on destroy against retire race

Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle.

[161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915active hint: i915vmaactive+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debugprintobject+0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CIDRM13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered intelwakerefputwork [i915] [161.360592] RIP: 0010:debugprintobject+0x80/0xb0 ... [161.361347] debugobjectfree+0xeb/0x110 [161.361362] i915activefini+0x14/0x130 [i915] [161.361866] releasereferences+0xfe/0x1f0 [i915] [161.362543] i915vmaparked+0x1db/0x380 [i915] [161.363129] gtpark+0x121/0x230 [i915] [161.363515] intelwakerefputlast+0x1f/0x70 [i915]

That has been tracked down to be happening when another thread is deactivating the VMA inside activeretire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool.

We could prevent from that race by serializing i915activefini() with activeretire() via ref->treelock, but that wouldn't stop the VMA from being used, e.g. from i915vmaretire() called at the end of activeretire(), after that VMA has been already freed by a concurrent i915vmadestroy() on return from the i915activefini(). Then, we should rather fix the issue at the VMA level, not in i915active.

Since i915vmaparked() is called from gtpark() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for activeretire() to complete before that wakeref is released and the GT parked.

I believe the issue was introduced by commit d93939730347 ("drm/i915: Remove the vma refcount") which moved a call to i915activefini() from a dropped i915vmarelease(), called on last put of the removed VMA kref, to i915vmaparked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915active that was fixed two weeks later with commit e92eb246feb9 ("drm/i915/active: Fix missing debug object activation").

A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intelcontext for a GT associated with its VM, and indirectly on that intelcontext's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation.

Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since i915vmaretire() may be called from atomic contexts, use async variant of wakeref put. Also, to avoid circular locking dependency, take care of acquiring the wakeref before VM mutex when both are needed.

v7: Add inline comments with justifications for: - using untracked variants of intelgtpmget/put() (Nirmoy), - using async variant of put(), - not getting the wakeref in case of a global GTT, - always getting the first wakeref outside vm->mutex. v6: Since i915vmaactive/retire() callbacks are not serialized, storing a wakeref tracking handle inside struct i915vma is not safe, and there is no other good place for that. Use untracked variants of intelgtpmget/putasync(). v5: Replace "tile" with "GT" across commit description (Rodrigo), - ---truncated---

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

drm/amdgpu: Fix potential out-of-bounds access in 'amdgpudiscoveryregbaseinit()'

The issue arises when the array 'adev->vcn.vcnconfig' is accessed before checking if the index 'adev->vcn.numvcninst' is within the bounds of the array.

The fix involves moving the bounds check before the array access. This ensures that 'adev->vcn.numvcninst' is within the bounds of the array before it is used as an index.

Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpudiscovery.c:1289 amdgpudiscoveryregbaseinit() error: testing array offset 'adev->vcn.numvcninst' after use.

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

RDMA/irdma: Fix drain SQ hang with no completion

SW generated completions for outstanding WRs posted on SQ after QP is in error target the wrong CQ. This causes the ibdrainsq to hang with no completion.

Fix this to generate completions on the right CQ.

[ 863.969340] INFO: task kworker/u52:2:671 blocked for more than 122 seconds. [ 863.979224] Not tainted 5.14.0-130.el9.x8664 #1 [ 863.986588] "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. [ 863.996997] task:kworker/u52:2 state:D stack: 0 pid: 671 ppid: 2 flags:0x00004000 [ 864.007272] Workqueue: xprtiod xprtautoclose [sunrpc] [ 864.014056] Call Trace: [ 864.017575] schedule+0x206/0x580 [ 864.022296] schedule+0x43/0xa0 [ 864.026736] scheduletimeout+0x115/0x150 [ 864.032185] waitforcommon+0x93/0x1d0 [ 864.037717] ? usleeprangestate+0x90/0x90 [ 864.043368] ibdrainsq+0xf6/0x170 [ibcore] [ 864.049371] ? rdmablockiternext+0x80/0x80 [ibcore] [ 864.056240] ibdrainsq+0x66/0x70 [ibcore] [ 864.062003] rpcrdmaxprtdisconnect+0x82/0x3b0 [rpcrdma] [ 864.069365] ? xprtpreparetransmit+0x5d/0xc0 [sunrpc] [ 864.076386] xprtrdmaclose+0xe/0x30 [rpcrdma] [ 864.082593] xprtautoclose+0x52/0x100 [sunrpc] [ 864.088718] processonework+0x1e8/0x3c0 [ 864.094170] workerthread+0x50/0x3b0 [ 864.099109] ? rescuerthread+0x370/0x370 [ 864.104473] kthread+0x149/0x170 [ 864.109022] ? setkthreadstruct+0x40/0x40 [ 864.114713] retfromfork+0x22/0x30

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

fbdev: Fix invalid page access after closing deferred I/O devices

The Linux kernel CVE team has assigned CVE-2023-52731 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052159-CVE-2023-52731-29ab@gregkh/T

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

wifi: ath11k: fix gtk offload status event locking

The ath11k active pdevs are protected by RCU but the gtk offload status event handling code calling ath11kmacgetarvifbyvdevid() was not marked as a read-side critical section.

Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.

Compile tested only.

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

drm/amd: check num of link levels when update pcie param

In SR-IOV environment, the value of pcietable->numoflinklevels will be 0, and numoflevels - 1 will cause array index out of bounds

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

IB/mlx5: Fix init stage error handling to avoid double free of same QP and UAF

In the unlikely event that workqueue allocation fails and returns NULL in mlx5mkeycacheinit(), delete the call to mlx5rumrresourcecleanup() (which frees the QP) in mlx5ibstagepostibregumrinit(). This will avoid attempted double free of the same QP when mlx5ibadd() does its cleanup.

Resolves a splat:

Syzkaller reported a UAF in ibdestroyqpuser

workqueue: Failed to create a rescuer kthread for wq "mkeycache": -EINTR infiniband mlx50: mlx5mkeycacheinit:981:(pid 1642): failed to create work queue infiniband mlx50: mlx5ibstagepostibregumrinit:4075:(pid 1642): mr cache init failed -12 ================================================================== BUG: KASAN: slab-use-after-free in ibdestroyqpuser (drivers/infiniband/core/verbs.c:2073) Read of size 8 at addr ffff88810da310a8 by task reproupstream/1642

Call Trace: <TASK> kasanreport (mm/kasan/report.c:590) ibdestroyqpuser (drivers/infiniband/core/verbs.c:2073) mlx5rumrresourcecleanup (drivers/infiniband/hw/mlx5/umr.c:198) mlx5ibadd (drivers/infiniband/hw/mlx5/main.c:4178) mlx5rprobe (drivers/infiniband/hw/mlx5/main.c:4402) ... </TASK>

Allocated by task 1642: kmalloc (./include/linux/kasan.h:198 mm/slabcommon.c:1026 mm/slabcommon.c:1039) createqp (./include/linux/slab.h:603 ./include/linux/slab.h:720 ./include/rdma/ibverbs.h:2795 drivers/infiniband/core/verbs.c:1209) ibcreateqpkernel (drivers/infiniband/core/verbs.c:1347) mlx5rumrresourceinit (drivers/infiniband/hw/mlx5/umr.c:164) mlx5ibstagepostibregumrinit (drivers/infiniband/hw/mlx5/main.c:4070) mlx5ibadd (drivers/infiniband/hw/mlx5/main.c:4168) mlx5rprobe (drivers/infiniband/hw/mlx5/main.c:4402) ...

Freed by task 1642: kmemcachefree (mm/slub.c:1826 mm/slub.c:3809 mm/slub.c:3822) ibdestroyqpuser (drivers/infiniband/core/verbs.c:2112) mlx5rumrresourcecleanup (drivers/infiniband/hw/mlx5/umr.c:198) mlx5ibstagepostibregumrinit (drivers/infiniband/hw/mlx5/main.c:4076 drivers/infiniband/hw/mlx5/main.c:4065) mlx5ibadd (drivers/infiniband/hw/mlx5/main.c:4168) mlx5rprobe (drivers/infiniband/hw/mlx5/main.c:4402) ...