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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
scsi: target: iscsi: Validate CHAPR length before base64 decode
chapservercomputehash() allocates clientdigest as kzalloc(chap->digestsize) and then, for BASE64-encoded responses, passes chapr directly to chapbase64decode() without checking whether the input length could produce more than digestsize bytes of output.
chapbase64decode() writes to the destination unconditionally as long as there is input to consume. With MAXRESPONSELENGTH set to 128 and the "0b" prefix stripped by extractparam(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digestsize=32) this overflows clientdigest by 63 bytes; for MD5 (digestsize=16) the overflow is 79 bytes.
The length check at line 344 fires after the write has already happened.
The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIVROUNDUP(digestsize 4, 3) before calling the decoder.
Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chapbase64decode() already returns early on '=', so the full original string is still passed to the decoder unchanged.
The mutual CHAP path decodes CHAPC into initiatorchgbinhex, which is kzalloc(CHAPCHALLENGESTRLEN). extractparam() caps initiatorchg at CHAPCHALLENGESTRLEN characters, so at most CHAPCHALLENGESTRLEN-1 base64 characters reach the decoder. The maximum decoded size, DIVROUNDUP((CHAPCHALLENGESTRLEN-1) 3, 4), is less than CHAPCHALLENGESTRLEN, so no overflow is possible there. A comment is added at the call site to document this.
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.
A use-after-free in the mac80211 stack when parsing a multi-BSSID element in the Linux kernel 5.2 through 5.19.x before 5.19.16 could be used by attackers (able to inject WLAN frames) to crash the kernel and potentially execute code.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix user-after-free
This uses l2capchanholdunlesszero() after calling l2capgetchanblah() to prevent the following trace:
Bluetooth: l2capcore.c:static void l2capchandestroy(struct kref kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in mutexwaiterisfirst kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in mutexlockcommon kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in mutexlock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix use-after-free
We've already freed the assocdata at this point, so need to use another copy of the AP (MLD) address instead.
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.
In the Linux kernel, the following vulnerability has been resolved:
iouring/afunix: defer registered files gc to iouring release
Instead of putting iouring's registered files in unixgc() we want it to be done by iouring itself. The trick here is to consider iouring registered files for cycle detection but not actually putting them down. Because iouring can't register other ring instances, this will remove all refs to the ring file triggering the ->release path and clean up with ioringctxfree().
[axboe: add kerneldoc comment to skb, fold in skb leak fix]
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio-ap: always filter entire AP matrix
The vfioapmdevfiltermatrix function is called whenever a new adapter or domain is assigned to the mdev. The purpose of the function is to update the guest's AP configuration by filtering the matrix of adapters and domains assigned to the mdev. When an adapter or domain is assigned, only the APQNs associated with the APID of the new adapter or APQI of the new domain are inspected. If an APQN does not reference a queue device bound to the vfioap device driver, then it's APID will be filtered from the mdev's matrix when updating the guest's AP configuration.
Inspecting only the APID of the new adapter or APQI of the new domain will result in passing AP queues through to a guest that are not bound to the vfioap device driver under certain circumstances. Consider the following:
guest's AP configuration (all also assigned to the mdev's matrix): 14.0004 14.0005 14.0006 16.0004 16.0005 16.0006
unassign domain 4 unbind queue 16.0005 assign domain 4
When domain 4 is re-assigned, since only domain 4 will be inspected, the APQNs that will be examined will be: 14.0004 16.0004
Since both of those APQNs reference queue devices that are bound to the vfioap device driver, nothing will get filtered from the mdev's matrix when updating the guest's AP configuration. Consequently, queue 16.0005 will get passed through despite not being bound to the driver. This violates the linux device model requirement that a guest shall only be given access to devices bound to the device driver facilitating their pass-through.
To resolve this problem, every adapter and domain assigned to the mdev will be inspected when filtering the mdev's matrix.
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix data races on remoteid
Similar to the previous patch, address the data race on remoteid, adding the suitable ONCE annotations.
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll
Use spinlockirqsave and spinunlockirqrestore instead of spinlock and spinunlock in mtkstaremac driver to avoid spinlock recursion occurrence that can happen when enabling the DMA interrupts again in rx/tx poll.
BUG: spinlock recursion on CPU#0, swapper/0/0 lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0, .ownercpu: 0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT Hardware name: MediaTek MT8365 Open Platform EVK (DT) Call trace: showstack+0x18/0x24 (C) dumpstacklvl+0x60/0x80 dumpstack+0x18/0x24 spindump+0x78/0x88 dorawspinlock+0x11c/0x120 rawspinlock+0x20/0x2c mtkstarhandleirq+0xc0/0x22c [mtkstaremac] handleirqeventpercpu+0x48/0x140 handleirqevent+0x4c/0xb0 handlefasteoiirq+0xa0/0x1bc handleirqdesc+0x34/0x58 generichandledomainirq+0x1c/0x28 gichandleirq+0x4c/0x120 dointerrupthandler+0x50/0x84 el1interrupt+0x34/0x68 el1h64irqhandler+0x18/0x24 el1h64irq+0x6c/0x70 regmapmmioread32le+0xc/0x20 (P) regmapbusregread+0x6c/0xac regmapread+0x60/0xdc regmapread+0x4c/0x80 mtkstarrxpoll+0x2f4/0x39c [mtkstaremac] napipoll+0x38/0x188 netrxaction+0x164/0x2c0 handlesoftirqs+0x100/0x244 dosoftirq+0x14/0x20 dosoftirq+0x10/0x20 callonirqstack+0x24/0x64 dosoftirqownstack+0x1c/0x40 irqexitrcu+0xd4/0x10c irqexitrcu+0x10/0x1c el1interrupt+0x38/0x68 el1h64irqhandler+0x18/0x24 el1h64irq+0x6c/0x70 cpuidleenterstate+0xac/0x320 (P) cpuidleenter+0x38/0x50 doidle+0x1e4/0x260 cpustartupentry+0x34/0x3c restinit+0xdc/0xe0 consoleonrootfs+0x0/0x6c primaryswitched+0x88/0x90
A buffer overflow flaw was found in the u8 overflow in cfg80211updatenotlistednontrans() in net/wireless/scan.c in the Linux kernel’s wifi subcomponent. This flaw allows an attacker to crash the system or leak internal kernel information.
In the Linux kernel, the following vulnerability has been resolved:
nvmet-auth: assign dhkey to NULL after kfreesensitive
ctrl->dhkey might be used across multiple calls to nvmetsetupdhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmetdestroyauth().
Found by Linux Verification Center (linuxtesting.org) with Svace.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: Fix UAF on isosocktimeout
conn->sk maybe have been unlinked/freed while waiting for isoconnlock so this checks if the conn->sk is still valid by checking if it part of isosklist.
A use-after-free in the function deltimer of the file drivers/isdn/mISDN/l1oipcore.c of the component Bluetooth in Linux Kernel could allow a remote authenticated attacker from within the local network to cause an unknown impact.
A vulnerability classified as critical has been found in Linux Kernel. This affects the function spl2swnvmemgetmacaddress of the file drivers/net/ethernet/sunplus/spl2swdriver.c of the component BPF. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier VDB-211041 was assigned to this vulnerability.
A use-after-free flaw was found in the Linux kernel MCTP (Management Component Transport Protocol) functionality. This issue occurs when a user simultaneously calls DROPTAG ioctl and socket close happens, which could allow a local user to crash the system or potentially escalate their privileges on the system.
In the Linux kernel, the following vulnerability has been resolved:
scsi: smartpqi: Fix disablemanagedinterrupts
Correct blk-mq registration issue with module parameter disablemanagedinterrupts enabled.
When we turn off the default PCIIRQAFFINITY flag, the driver needs to register with blk-mq using blkmqmapqueues(). The driver is currently calling blkmqpcimapqueues() which results in a stack trace and possibly undefined behavior.
Stack Trace: [ 7.860089] scsi host2: smartpqi [ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blkmqpcimapqueues+0xca/0xd0 [ 7.889231] Modules linked in: sdmod t10pi sg uas smartpqi(+) crc32cintel scsitransportsas usbstorage dmmirror dmregionhash dmlog dmmod ipmidevintf ipmimsghandler fuse [ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el86smartpqitest.x8664 #1 [ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022 [ 7.963026] Workqueue: events workforcpufn [ 7.978275] RIP: 0010:blkmqpcimapqueues+0xca/0xd0 [ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010 [ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00 [ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8.172818] PKRU: 55555554 [ 8.172819] Call Trace: [ 8.172823] blkmqalloctagset+0x12e/0x310 [ 8.264339] scsiaddhostwithdma.cold.9+0x30/0x245 [ 8.279302] pqictrlinit+0xacf/0xc8e [smartpqi] [ 8.294085] ? pqipciprobe+0x480/0x4c8 [smartpqi] [ 8.309015] pqipciprobe+0x480/0x4c8 [smartpqi] [ 8.323286] localpciprobe+0x42/0x80 [ 8.337855] workforcpufn+0x16/0x20 [ 8.351193] processonework+0x1a7/0x360 [ 8.364462] ? createworker+0x1a0/0x1a0 [ 8.379252] workerthread+0x1ce/0x390 [ 8.392623] ? createworker+0x1a0/0x1a0 [ 8.406295] kthread+0x10a/0x120 [ 8.418428] ? setkthreadstruct+0x50/0x50 [ 8.431532] retfromfork+0x1f/0x40 [ 8.444137] ---[ end trace 1bf0173d39354506 ]---
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in port "disable" sysfs attribute
The show and store callback routines for the "disable" sysfs attribute file in port.c acquire the device lock for the port's parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration:
Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and devicedel() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can't be released until then.
But the disableshow() or disablestore() routine can't return until after it has acquired the lock.
The resulting deadlock can be avoided by calling sysfsbreakactiveprotection(). This will cause the sysfs core not to wait for the attribute's callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won't be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hubget().
In the Linux kernel, the following vulnerability has been resolved:
iouring/net: fix overflow check in iorecvmsgmshotprep()
The "controllen" variable is type sizet (unsigned long). Casting it to int could lead to an integer underflow.
The checkaddoverflow() function considers the type of the destination which is type int. If we add two positive values and the result cannot fit in an integer then that's counted as an overflow.
However, if we cast "controllen" to an int and it turns negative, then negative values can fit into an int type so there is no overflow.
Good: 100 + (unsigned long)-4 = 96 <-- overflow Bad: 100 + (int)-4 = 96 <-- no overflow
I deleted the cast of the sizeof() as well. That's not a bug but the cast is unnecessary.