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

nvmet-auth: validate reply message payload bounds against transfer length

nvmetauthreply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes.

A malicious NVMe-oF initiator can craft a DHCHAPREPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2hl) or performs the host response memcmp.

With DH authentication configured, the OOB pointer is passed directly to sginitone() and read by cryptokppcomputesharedsecret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication.

Add bounds validation ensuring sizeof(data) + 2hl + dhvlen <= tl before any access to the variable-length fields.

Discovered by Atuin - Automated Vulnerability Discovery Engine.

9p: avoid putting oldfid in p9clientwalk() error path

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

svcrdma: bound check rqpages index in inline path

svcrdmacopyinlinerange indexed rqstp->rqpages[rccurpage] without verifying rccurpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.

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

tls: make sure to abort the stream if headers are bogus

Normally we wait for the socket to buffer up the whole record before we service it. If the socket has a tiny buffer, however, we read out the data sooner, to prevent connection stalls. Make sure that we abort the connection when we find out late that the record is actually invalid. Retrying the parsing is fine in itself but since we copy some more data each time before we parse we can overflow the allocated skb space.

Constructing a scenario in which we're under pressure without enough data in the socket to parse the length upfront is quite hard. syzbot figured out a way to do this by serving us the header in small OOB sends, and then filling in the recvbuf with a large normal send.

Make sure that tlsrxmsgsize() aborts strp, if we reach an invalid record there's really no way to recover.

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

tls: fix handling of zero-length records on the rxlist

Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record

If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rxlist. Next recvmsg() will pick it up from there.

Queuing the skb to rxlist after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rxlist, and it's zero length.

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

RDMA/erdma: Prevent use-after-free in erdmaacceptnewconn()

After the erdmacepput(newcep) being called, newcep will be freed, and the following dereference will cause a UAF problem. Fix this issue.

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

RDMA/rxe: Fix the warning "rxecleanup+0x12c/0x170 [rdmarxe]"

The Call Trace is as below: " <TASK> ? showregs.cold+0x1a/0x1f ? rxecleanup+0x12c/0x170 [rdmarxe] ? warn+0x84/0xd0 ? rxecleanup+0x12c/0x170 [rdmarxe] ? reportbug+0x105/0x180 ? handlebug+0x46/0x80 ? excinvalidop+0x19/0x70 ? asmexcinvalidop+0x1b/0x20 ? rxecleanup+0x12c/0x170 [rdmarxe] ? rxecleanup+0x124/0x170 [rdmarxe] rxedestroyqp.cold+0x24/0x29 [rdmarxe] ibdestroyqpuser+0x118/0x190 [ibcore] rdmadestroyqp.cold+0x43/0x5e [rdmacm] rtrscqqpdestroy.cold+0x1d/0x2b [rtrscore] rtrssrvclosework.cold+0x1b/0x31 [rtrsserver] processonework+0x21d/0x3f0 workerthread+0x4a/0x3c0 ? processonework+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30 </TASK> " When too many rdma resources are allocated, rxe needs more time to handle these rdma resources. Sometimes with the current timeout, rxe can not release the rdma resources correctly.

Compared with other rdma drivers, a bigger timeout is used.

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

PCI: dwc: ep: Prevent changing BAR size/flags in pciepcsetbar()

In commit 4284c88fff0e ("PCI: designware-ep: Allow pciepcsetbar() update inbound map address") setbar() was modified to support dynamically changing the backing physical address of a BAR that was already configured.

This means that setbar() can be called twice, without ever calling clearbar() (as calling clearbar() would clear the BAR's PCI address assigned by the host).

This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks.

If we allow setbar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pciepfbar.

While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.)

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

smb: client: fix potential UAF in isvalidoplockbreak()

Skip sessions that are being teared down (status == SESEXITING) to avoid UAF.

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

net: tls: fix use-after-free with partial reads and async decrypt

tlsdecryptsg doesn't take a reference on the pages from clearskb, so the putpage() in tlsdecryptdone releases them, and we trigger a use-after-free in processrxlist when we try to read from the partially-read skb.

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

NFSD: Protect against send buffer overflow in NFSv2 READ

Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time.

Once an RPC Call has been received, svcprocess() updates svcrqst::rqres to describe the part of rqpages that can be used for constructing the Reply. This means that the send buffer (rqres) shrinks when the received RPC record containing the RPC Call is large.

A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case.

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

fs: dlm: fix race in lowcomms

This patch fixes a race between queuework() in dlmlowcommscommitmsg() and srcureadunlock(). The queuework() can take the final reference of a dlmmsg and so msg->idx can contain garbage which is signaled by the following warning:

[ 676.237050] ------------[ cut here ]------------ [ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlmlowcommscommitmsg+0x41/0x50 [ 676.238945] Modules linked in: dlmlocktorture torture rpcsecgsskrb5 intelraplmsr intelraplcommon iTCOwdt iTCOvendorsupport qxl kvmintel drmttmhelper vmwvsockvirtiotransport kvm vmwvsockvirtiotransportcommon ttm irqbypass crc32pclmul joydev crc32cintel serioraw drmkmshelper vsock virtioscsi virtioconsole virtioballoon sndpcm drm syscopyarea sysfillrect sysimgblt sndtimer fbsysfops i2ci801 lpcich snd i2csmbus soundcore pcspkr [ 676.244227] CPU: 0 PID: 1060 Comm: locktorturewr Not tainted 5.19.0-rc3+ #1546 [ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 676.246460] RIP: 0010:dlmlowcommscommitmsg+0x41/0x50 [ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 [ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282 [ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006 [ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e [ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001 [ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005 [ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480 [ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000 [ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0 [ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 676.258397] PKRU: 55555554 [ 676.258729] Call Trace: [ 676.259063] <TASK> [ 676.259354] dlmmidcommscommitmhandle+0xcc/0x110 [ 676.259964] queuebast+0x8b/0xb0 [ 676.260423] grantpendinglocks+0x166/0x1b0 [ 676.261007] unlocklock+0x75/0x90 [ 676.261469] unlocklock.isra.57+0x62/0xa0 [ 676.262009] dlmunlock+0x21e/0x330 [ 676.262457] ? locktorturestats+0x80/0x80 [dlmlocktorture] [ 676.263183] tortureunlock+0x5a/0x90 [dlmlocktorture] [ 676.263815] ? preemptcountsub+0xba/0x100 [ 676.264361] ? complete+0x1d/0x60 [ 676.264777] locktorturewriter+0xb8/0x150 [dlmlocktorture] [ 676.265555] kthread+0x10a/0x130 [ 676.266007] ? kthreadcompleteandexit+0x20/0x20 [ 676.266616] retfromfork+0x22/0x30 [ 676.267097] </TASK> [ 676.267381] irq event stamp: 9579855 [ 676.267824] hardirqs last enabled at (9579863): [<ffffffffbb14e6f8>] upconsolesem+0x58/0x60 [ 676.268896] hardirqs last disabled at (9579872): [<ffffffffbb14e6dd>] upconsolesem+0x3d/0x60 [ 676.270008] softirqs last enabled at (9579798): [<ffffffffbc200349>] dosoftirq+0x349/0x4c7 [ 676.271438] softirqs last disabled at (9579897): [<ffffffffbb0d54c0>] irqexitrcu+0xb0/0xf0 [ 676.272796] ---[ end trace 0000000000000000 ]---

I reproduced this warning with dlmlocktorture test which is currently not upstream. However this patch fix the issue by make a additional refcount between dlmlowcommsnewmsg() and dlmlowcommscommitmsg(). In case of the race the krefput() in dlmlowcommscommitmsg() will be the final put.

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

skmsg: pass gfp argument to allocskmsg()

syzbot found that allocskmsg() could be called from a non sleepable context. skpsockverdictrecv() uses rcureadlock() protection.

We need the callers to pass a gfpt argument to avoid issues.

syzbot report was:

BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 inatomic(): 0, irqsdisabled(): 0, nonblock: 0, pid: 3613, name: syz-executor414 preemptcount: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e3/0x2cb lib/dumpstack.c:106 mightresched+0x538/0x6a0 kernel/sched/core.c:9877 mightalloc include/linux/sched/mm.h:274 [inline] slabpreallochook mm/slab.h:700 [inline] slaballocnode mm/slub.c:3162 [inline] slaballoc mm/slub.c:3256 [inline] kmemcachealloctrace+0x59/0x310 mm/slub.c:3287 kmalloc include/linux/slab.h:600 [inline] kzalloc include/linux/slab.h:733 [inline] allocskmsg net/core/skmsg.c:507 [inline] skpsockskbingressself+0x5c/0x330 net/core/skmsg.c:600 skpsockverdictapply+0x395/0x440 net/core/skmsg.c:1014 skpsockverdictrecv+0x34d/0x560 net/core/skmsg.c:1201 tcpreadskb+0x4a1/0x790 net/ipv4/tcp.c:1770 tcprcvestablished+0x129d/0x1a10 net/ipv4/tcpinput.c:5971 tcpv4dorcv+0x479/0xac0 net/ipv4/tcpipv4.c:1681 skbacklogrcv include/net/sock.h:1109 [inline] releasesock+0x1d8/0x4c0 net/core/sock.c:2906 releasesock+0x5d/0x1c0 net/core/sock.c:3462 tcpsendmsg+0x36/0x40 net/ipv4/tcp.c:1483 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline] syssendto+0x46d/0x5f0 net/socket.c:2117 dosyssendto net/socket.c:2129 [inline] sesyssendto net/socket.c:2125 [inline] x64syssendto+0xda/0xf0 net/socket.c:2125 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

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

NFSD: Protect against send buffer overflow in NFSv2 READDIR

Restore the previous limit on the @count argument to prevent a buffer overflow attack.

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

USB: core: Fix access violation during port device removal

Testing with KASAN and syzkaller revealed a bug in port.c:disablestore(): usbhubtostructhub() can return NULL if the hub that the port belongs to is concurrently removed, but the function does not check for this possibility before dereferencing the returned value.

It turns out that the first dereference is unnecessary, since hub->intfdev is the parent of the port device, so it can be changed easily. Adding a check for hub == NULL prevents further problems.

The same bug exists in the disableshow() routine, and it can be fixed the same way.