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:

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.

An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c has a use-after-free and OOPS for SMB2TREEDISCONNECT.

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:

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.

An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is a heap-based buffer overflow in setntacldacl, related to use of SMB2QUERYINFOHE after a malformed SMB2SETINFOHE command.

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

mptcp: allow subflow rcv wnd to shrink

In MPTCP connection, the window field in the TCP header refers to the MPTCP-level rcvnxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time.

At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog).

As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving.

Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.

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.

bpf: Fix overloading of MEMUNINIT's meaning

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

media: imx-jpeg: Align upwards buffer size

The hardware can support any image size WxH, with arbitrary W (image width) and H (image height) dimensions.

Align upwards buffer size for both encoder and decoder. and leave the picture resolution unchanged.

For decoder, the risk of memory out of bounds can be avoided. For both encoder and decoder, the driver will lift the limitation of resolution alignment.

For example, the decoder can support jpeg whose resolution is 227x149 the encoder can support nv12 1080P, won't change it to 1920x1072.

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

netfilter: nftables: do not allow CHAINID to refer to another table

When doing lookups for chains on the same batch by using its ID, a chain from a different table can be used. If a rule is added to a table but refers to a chain in a different table, it will be linked to the chain in table2, but would have expressions referring to objects in table1.

Then, when table1 is removed, the rule will not be removed as its linked to a chain in table2. When expressions in the rule are processed or removed, that will lead to a use-after-free.

When looking for chains by ID, use the table that was used for the lookup by name, and only return chains belonging to that same table.

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:

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:

HID: mcp2221: prevent a buffer overflow in mcpsmbuswrite()

Smatch Warning: drivers/hid/hid-mcp2221.c:388 mcpsmbuswrite() error: memcpy() '&mcp->txbuf[5]' too small (59 vs 255) drivers/hid/hid-mcp2221.c:388 mcpsmbuswrite() error: memcpy() 'buf' too small (34 vs 255)

The 'len' variable can take a value between 0-255 as it can come from data->block[0] and it is user data. So add an bound check to prevent a buffer overflow in memcpy().

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

nfsd: fix RELEASELOCKOWNER

The Linux kernel CVE team has assigned CVE-2024-26629 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/20240313140155.1913910-4-lee@kernel.org/T

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

crypto: hisilicon/sec - don't sleep when in softirq

When kunpeng920 encryption driver is used to deencrypt and decrypt packets during the softirq, it is not allowed to use mutex lock. The kernel will report the following error:

BUG: scheduling while atomic: swapper/57/0/0x00000300 Call trace: dumpbacktrace+0x0/0x1e4 showstack+0x20/0x2c dumpstack+0xd8/0x140 schedulebug+0x68/0x80 schedule+0x728/0x840 schedule+0x50/0xe0 schedulepreemptdisabled+0x18/0x24 mutexlock.constprop.0+0x594/0x5dc mutexlockslowpath+0x1c/0x30 mutexlock+0x50/0x60 secrequestinit+0x8c/0x1a0 [hisisec2] secprocess+0x28/0x1ac [hisisec2] secskciphercrypto+0xf4/0x1d4 [hisisec2] secskcipherencrypt+0x1c/0x30 [hisisec2] cryptoskcipherencrypt+0x2c/0x40 cryptoauthencencrypt+0xc8/0xfc [authenc] cryptoaeadencrypt+0x2c/0x40 echainivencrypt+0x144/0x1a0 [echainiv] cryptoaeadencrypt+0x2c/0x40 espoutputtail+0x348/0x5c0 [esp4] espoutput+0x120/0x19c [esp4] xfrmoutputone+0x25c/0x4d4 xfrmoutputresume+0x6c/0x1fc xfrmoutput+0xac/0x3c0 xfrm4output+0x64/0x130 ipbuildandsendpkt+0x158/0x20c tcpv4sendsynack+0xdc/0x1f0 tcpconnrequest+0x7d0/0x994 tcpv4connrequest+0x58/0x6c tcpv6connrequest+0xf0/0x100 tcprcvstateprocess+0x1cc/0xd60 tcpv4dorcv+0x10c/0x250 tcpv4rcv+0xfc4/0x10a4 ipprotocoldeliverrcu+0xf4/0x200 iplocaldeliverfinish+0x58/0x70 iplocaldeliver+0x68/0x120 ipsublistrcvfinish+0x70/0x94 iplistrcvfinish.constprop.0+0x17c/0x1d0 ipsublistrcv+0x40/0xb0 iplistrcv+0x140/0x1dc netifreceiveskblistcore+0x154/0x28c netifreceiveskblist+0x120/0x1a0 netifreceiveskblistinternal+0xe4/0x1f0 napicompletedone+0x70/0x1f0 grocellpoll+0x9c/0xb0 napipoll+0xcc/0x264 netrxaction+0xd4/0x21c dosoftirq+0x130/0x358 irqexit+0x11c/0x13c handledomainirq+0x88/0xf0 gichandleirq+0x78/0x2c0 el1irq+0xb8/0x140 archcpuidle+0x18/0x40 defaultidlecall+0x5c/0x1c0 cpuidleidlecall+0x174/0x1b0 doidle+0xc8/0x160 cpustartupentry+0x30/0x11c secondarystartkernel+0x158/0x1e4 softirq: huh, entered softirq 3 NETRX 0000000093774ee4 with preemptcount 00000100, exited with fffffe00?

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:

lockd: set other missing fields when unlocking files

vfslockfile() expects the struct filelock to be fully initialised by the caller. Re-exported NFSv3 has been seen to Oops if the flfile field is NULL.

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

netfilter: nfconncount: update lastgc only when GC has been performed

Currently lastgc is being updated everytime a new connection is tracked, that means that it is updated even if a GC wasn't performed. With a sufficiently high packet rate, it is possible to always bypass the GC, causing the list to grow infinitely.

Update the lastgc value only when a GC has been actually performed.

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.

An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is an out-of-bounds read and OOPS for SMB2WRITE, when there is a large length in the zero DataOffset case.

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.