generated 2026-10-15 05:02 UTC
Web / App Stack, published 2026-10-14
Flagged for matching PHP.
e107 is a content management system (CMS). Prior to 2.3.7, install.php decodes the attacker-controlled previoussteps POST parameter and passes it to unserialize() at file scope and again in the einstall constructor without restricting allowed classes. The installer remains accessible after a normal installation, and a crafted object graph using the bundled GuzzleHttp\Psr7\PumpStream class can flow through paths.hash into site_path, where string coercion invokes an attacker-controlled callable. An unauthenticated attacker who can reach install.php can therefore execute arbitrary PHP functions with the web server process's privileges, leading to full server compromise. This issue is fixed in version 2.3.7.
In practice: exploitable over the network, requires no privileges, needs no user interaction.
References:
Web / App Stack, published 2026-10-14
Flagged for matching MariaDB.
WeGIA is a web manager for charitable institutions. Prior to 3.8.6, unauthenticated POST requests to web/html/socio/sistema/cadastrocobranca.php can place a quoted SQL expression in the codigo parameter, which extract($REQUEST) passes into the WHERE codigo= clause of an UPDATE statement without validation or parameter binding. Quoting the value bypasses MariaDB type conversion for the VARCHAR column and permits arbitrary SQL execution without a session. An attacker can read or modify database content, including user credential hashes and billing records in the cobrancas table. This issue is fixed in version 3.8.6.
In practice: exploitable over the network, requires no privileges, needs no user interaction.
References:
Web / App Stack, published 2026-10-15
Flagged for matching MySQL.
Wheels 1.1.8 through 4.1.1 allows SQL injection when caller-supplied quoted values are parsed again as SQL by dynamic finders (such as findOneByEmail), the query builder's where(property, value) and where(property, operator, value), string/UUID-key lookup paths (findByKey, updateByKey, deleteByKey and findOrCreateBy...), and validatesUniquenessOf. The parser incorrectly treats a doubled single quote as the end of a literal. Applications passing request data to these APIs can expose authentication, password-reset or token lookups, and data to unauthorized access; numeric-column values are not affected. There is a similar concern for query-builder whereBetween() in 4.0.0 through 4.1.1: string/date bounds can alter SQL on MySQL/MariaDB with backslash escaping enabled. This is fixed in 4.1.2.
In practice: exploitable over the network, requires no privileges, needs no user interaction.
References:
Containers, published 2026-10-14
Flagged for matching Docker.
Dokku is a docker-powered platform as a service. In Dokku versions before 0.38.25, a user with app-level Dokku access and remote SSH access to execute docker-options commands can store arbitrary strings through the docker-options plugin, and those strings are later concatenated into DOCKER_ARGS and processed by Bash eval during build, deploy, or run operations. Shell command substitutions in the stored values are interpreted on the host, allowing arbitrary command execution with the privileges of the dokku operating-system user. This issue is fixed in version 0.38.25.
In practice: exploitable over the network, requires low privileges, needs user interaction.
References:
Web / App Stack, published 2026-10-14
Flagged for matching nginx.
Description
NGINX Gateway Fabric has a vulnerability when it renders the spec.basic.realm (and spec.jwt.realm) field of a namespaced AuthenticationFilter verbatim, unescaped and unvalidated, into the shared data-plane nginx.conf as auth_basic "<realm>";. A namespaced authenticated attacker that configures AuthenticationFilter CRD to an HTTPRoute/GRPCRoute on a shared Gateway can craft a realm value that closes the quoted directive and the enclosing location {} block and injects arbitrary NGINX directives into that Gateway's data-plane config.
Impact
A remote authenticated attacker can send crafted requests to configure NGINX Gateway Fabric AuthenticationFilter CRD and may be able to read every co-located tenant's mounted secrets, SSRF via proxy_pass, reading the pod ServiceAccount token, or hijacking other tenants' routes. There is no data plane exposure; this is a control plane issue only.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
In practice: exploitable over the network, requires low privileges, needs no user interaction.
References:
Web / App Stack, published 2026-10-14
Flagged for matching PHP.
ILIAS before 9.24, 10.12, and 11.5 contains a PHP object injection vulnerability that allows authenticated users with Test creation or import permission to deserialize arbitrary objects via crafted Test archives. Attackers can inject a malicious tst_sequence sequence attribute that is passed to unserialize(), abusing Guzzle or Monolog gadget chains to write PHP files and execute code.
In practice: exploitable over the network, requires low privileges, needs no user interaction.
References:
Web / App Stack, published 2026-10-14
Flagged for matching nginx.
A vulnerability exists in NGINX Plus and NGINX Open Source when a location is configured that uses the alias directive together with rewrite and a set or return directive referencing the $requestfilename variable. Alternatively, the same result could be achieved when the $requestfilename variable is used in an access log format directive. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.
Impact:
This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution. There is no control plane exposure; this is a data plane issue only.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
In practice: exploitable over the network, requires no privileges, needs no user interaction.
References:
Web / App Stack, published 2026-10-14
Flagged for matching nginx.
A vulnerability exists in NGINX Plus and NGINX Open Source when a map directive uses regex matching and the root directive or access log format references the map's regex capture variables before referencing the map output variable. Alternatively, the same result could be achieved by using a non-cacheable variable in a string expression under certain conditions. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.
Impact:
This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution. There is no control plane exposure; this is a data plane issue only.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
In practice: exploitable over the network, requires no privileges, needs no user interaction.
References:
Web / App Stack, published 2026-10-14
Flagged for matching nginx.
NGINX Plus and NGINX Open Source have a vulnerability in the ngxhttpcore_module module. When asynchronous file I/O (AIO) is enabled in certain configurations, processing a Server Side Includes (SSI) page containing “include virtual” commands may trigger a Use-After-Free (UAF) in the NGINX worker process. This may cause memory corruption or a worker process crash. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.
Impact:
This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system, corrupt its memory, or possibly trigger code execution. There is no control plane exposure; this is a data plane issue only.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
In practice: exploitable over the network, requires no privileges, needs no user interaction.
References:
Web / App Stack, published 2026-10-14
Flagged for matching PHP.
The ShopMagic – email automation for WordPress plugin for WordPress is vulnerable to Local File Inclusion in all versions up to, and including, 4.9.0 via the 'billingaddress.firstname' parameter parameter. This makes it possible for unauthenticated attackers to include and execute arbitrary .php files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where .php file types can be uploaded and included. Exploitation requires a published recipe that processes the {{ customer.first_name }} placeholder — the plugin's built-in "New Order email with social media profile links" recipe satisfies this requirement out of the box, making the default configuration exploitable with no account, cookie, or nonce by simply submitting a guest checkout with the payload as the billing first name.
In practice: exploitable over the network, requires no privileges, needs no user interaction.
References:
Web / App Stack, published 2026-10-14
Flagged for matching PHP.
The Mang Board plugin for WordPress is vulnerable to Local File Inclusion in all versions up to, and including, 2.4.3 via the '<mode>type (e.g. footype)' parameter parameter. This makes it possible for unauthenticated attackers to include and execute arbitrary .php files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where .php file types can be uploaded and included. Exploitation is trivial via an unauthenticated POST to any page rendering a public [mb_board] shortcode, as no nonce or capability check is enforced on the shortcode render path; on servers with a standard PHP installation, pearcmd.php can be leveraged to write and then include an attacker-controlled payload file in a single request.
In practice: exploitable over the network, requires no privileges, needs no user interaction.
References:
Web / App Stack, published 2026-10-14
Flagged for matching PHP.
Beganovich snappdf from 1.1.0 before 6.1.0 contains an OS command injection vulnerability on Windows that allows attackers to run commands by influencing the rendered URL. Attackers can supply cmd.exe metacharacters such as & in the setUrl() value, which executeOnWindows() passes unescaped to PHP exec(), executing commands as the PHP process.
In practice: exploitable over the network, requires no privileges, needs no user interaction.
References:
Web / App Stack, published 2026-10-14
Flagged for matching PHP.
WeGIA is a web manager for charitable institutions. Prior to 3.8.6, the auto-prepended web/html/seguranca/sessionStart.php reflects an attacker-supplied PHPSESSID cookie in a Set-Cookie response and uses DB_HOST as the cookie domain. If a victim authenticates while using the attacker-selected identifier, the attacker can reuse that identifier to hijack the authenticated session. The response also discloses the internal database host name through the cookie Domain attribute, and the vulnerable session handler affects all PHP pages. This issue is fixed in version 3.8.6.
In practice: exploitable over the network, requires no privileges, needs user interaction.
References:
Operating Systems, Remote Access / Networking, published 2026-10-14
Flagged for matching FreeBSD, OpenSSH.
Improper neutralization of special elements in the NetBird client SSH configuration manager (client/ssh/config/manager.go) in NetBird versions 0.60.0 through 0.74.6 allows a malicious or compromised peer to execute arbitrary commands on other NetBird client hosts. The client writes a system-wide OpenSSH drop-in file (/etc/ssh/sshconfig.d/99-netbird.conf, or the equivalent under %PROGRAMDATA%\ssh\sshconfig.d on Windows) that embeds each peer FQDN or hostname inside a double-quoted Match host directive without escaping. A peer name containing a double quote breaks out of the quoted context and injects arbitrary SSH configuration directives, including exec commands, which run locally as any user on the host the next time that user runs ssh. Desktop clients on Linux, macOS, Windows and FreeBSD are affected; the Android and iOS apps are not. The issue is fixed in version 0.74.7, which accepts a peer FQDN or hostname only if it is a valid DNS name.
In practice: exploitable over the network, requires high privileges, needs no user interaction.
References:
Linux Kernel, Virtualization/Hypervisors, published 2026-10-14
Flagged for matching Linux kernel, QEMU.
In the Linux kernel, the following vulnerability has been resolved:
powerpc: Do not restore KUAP in archexittousermode_prepare()
KUAP means kernel cannot touch user memory unless it explicitly is
enabled. In the kernel it should stay AMRKUAPBLOCKED. While returning
to userspace just before RFI, kernel should restore the user AMR value
back.
Looks like GENERICENTRY might be treating archexittousermodeprepare()
as the last architecture step before returning to userspace.
commit bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature")
therefore called kuapuserrestore() from that hook. But on PowerPC that
is too early. After irqentryexit() / syscallexittouser_mode() we
still run platform specific exit routines.
e.g. code snippets showing both exception handling and system call
handling as the callers of function archexittousermode_prepare()
which does kuapuserrestore(). The below path shows that calling
kuapuserrestore() is too early when called from
archexittousermode_prepare().
Exception handling in exceptions-64s.S
=======================================
bl CFUNC(dopagefault)
..DEFINEINTERRUPTHANDLERASYNC(dopage_fault)
archinterruptasyncenterprepare(regs);
state = irqentry_enter(regs);
instrumentation_begin();
irqenterrcu();
handler(regs);
napadjustreturn(regs);
irqexitrcu();
instrumentation_end();
archinterruptasyncexitprepare(regs);
irqentry_exit(regs, state); <<< too early
irqentryexittousermode()
__exittousermodeprepare(regs, EXITTOUSERMODEWORK_IRQ);
archexittousermodeprepare(regs, tiwork); <<< too early
b interruptreturnsrr
.. bl CFUNC(interruptexituserprepare) <<< already calls kuapuser_restore
prepirqforenabledexit() retry can run kernel code with IRQs on. So
only when that routine is fully finished is when the user KUAP should be
fully restored which interruptexituser_prepare() already takes care of
before returning.
Similarly for system call handling in interrupt_64.S
======================================================
bl CFUNC(systemcallexception)
.Lsyscall_exit:
addi r4,r1,STACKINTFRAME_REGS
li r5,0 / !scv /
bl CFUNC(syscallexitprepare)
.. kuapassertlocked();
syscallexittousermode(regs); <<< too early
syscallexittousermode_prepare(regs); <<< too early
kuapuserrestore(regs); <<< already calls
syscallexitprepare(), which can enable IRQs, replay a pending
interrupt, and only then rfi. Those functions already restore KUAP
immediately before rfi.
Note that if we restore the user AMR too early like in the current code
as shown from the code snippets above, then we get the following warning
when CONFIGPPCKUAP_DEBUG is enabled:
WARNING: arch/powerpc/include/asm/book3s/64/kup.h:293 at interruptexituser_prepare+0x1a0/0x1c0
Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected)
TRAP: 0700
LR: c00000000000d8d4 CTR: c0000000021fe500
MSR: <SF,EE,ME,IR,DR,RI,LE> CR: 44000804 XER: 20040000
interruptexituser_prepare+0x1a0/0x1c0
interruptreturnsrr_user+0x8/0x12c
References:
Linux Kernel, Virtualization/Hypervisors, published 2026-10-14
Flagged for matching Linux kernel, QEMU.
In the Linux kernel, the following vulnerability has been resolved:
s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block
Unlike kdump, which passes the re-IPL parameter block through os_info,
the stand-alone dump passes it through the IPL parm block address and
checksum in lowcore.
Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not
provide an IPL parameter block. In this case reipltypeinit() selects
IPLTYPEUNKNOWN and reiplblockactual remains NULL. Nevertheless,
dumpreiplrun() unconditionally dereferences it when preparing the
lowcore fields. This may happen to work by chance when address zero
contains readable lowcore data. A zero IPL parameter block address is
then stored in lowcore, causing the stand-alone dumper to enter disabled
wait after completing the dump.
Explicitly store a zero IPL parameter block address and checksum when no
re-IPL parameter block is available. This does not change the behavior:
the stand-alone dumper completes the dump and halts, while valid re-IPL
parameter blocks continue to be handled as before.
References:
Linux Kernel, Virtualization/Hypervisors, published 2026-10-14
Flagged for matching Linux kernel, QEMU.
In the Linux kernel, the following vulnerability has been resolved:
s390/ipl: Fix NULL deref in kdump without re-IPL parm block
Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might
not provide an IPL parameter block. In this case, reipltypeinit()
selects IPLTYPEUNKNOWN, and reiplblockactual remains NULL.
kdump passes the re-IPL parameter block to the dump kernel through
os_info. Before commit 3b9678472bab ("s390/ipl: correct kdump reipl
block checksum calculation"), the os_info entry was added only for
IPL types which initialized reiplblockactual. That commit moved the
osinfo update to machinecrash_shutdown(), making it unconditional. As
a result, setosinforeiplblock() dereferences reiplblockactual for
IPLTYPEUNKNOWN. This may happen to work by chance when address zero
contains readable lowcore data and the resulting empty os_info entry is
ignored by the dump kernel.
Skip the os_info update when no re-IPL parameter block is available.
Kdump then collect the dump and reboot without setting re-IPL parameter
block.
References:
Linux Kernel, Virtualization/Hypervisors, published 2026-10-14
Flagged for matching Linux kernel, QEMU.
In the Linux kernel, the following vulnerability has been resolved:
net: iptunnel: fix stale transport header during tunnel decapsulation
Syzbot reported a crash in qdiscpktlensegsinit() caused by a stale
transport_header offset after tunnel decapsulation.
BUG: unable to handle page fault for address: ffffed102091a42e
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 340 Comm: qdiscuafrepro Not tainted 7.2.0-rc4-00061-g248951ddc14d #256 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__asan_load2
<IRQ>
qdiscpktlensegsinit (net/core/dev.c:4145)
__devqueuexmit (net/core/dev.c:4787)
brdevqueuepushxmit (net/bridge/br_forward.c:53)
brhandleframefinish (net/bridge/brinput.c:229)
brhandleframe (net/bridge/br_input.c:315)
__netifreceiveskb_core.constprop.0 (net/core/dev.c:6099)
__netifreceiveskblistcore (net/core/dev.c:6287)
netifreceiveskblistinternal (net/core/dev.c:6445)
napicompletedone (net/core/dev.c:6813)
grocellpoll (net/core/gro_cells.c:74)
__napi_poll (net/core/dev.c:7735)
netrxaction (net/core/dev.c:7798 net/core/dev.c:7955)
handle_softirqs (kernel/softirq.c:622)
do_softirq (kernel/softirq.c:523 kernel/softirq.c:510 )
__localbhenable_ip (kernel/softirq.c:450)
tungetuser (drivers/net/tun.c:1986 (discriminator 1))
tunchrwrite_iter (drivers/net/tun.c:2032)
The issue is completely latent until qdisc read transport header in
commit 7fb4c1967011 ("net: pull headers in qdiscpktlensegsinit()").
The crash requires four conditions to line up:
transport header offset is stored in skb->transport_header while the
packet is still in the outer tunnel context.
the inner frame, but skb->transport_header is left pointing to the
now-removed outer L4 header, so it becomes a negative offset relative to
the new data.
is forwarded at L2 by a bridge or HSR, so iprcvcore() never runs and
the transport header is not reset to the inner L4 offset.
qdiscpktlensegsinit(). That function computes the GSO header length
from skbtransportoffset(skb). Because the offset is negative, the
unsigned cast overflows and pskbmaypull(skb, hdr_len +
sizeof(struct tcphdr)) reads past the end of the skb, triggering a
KASAN fault or page fault.
The issue specifically requires GSO packets (shinfo->gso_size != 0), which
are processed/aggregated through gro_cells. Fix this by clearing
transportheader to the ~0U sentinel in grocell for all tunnnel driver.
GTP does not support GRO/GSO, drop the evil GSO packets in GTP directly.
References:
Linux Kernel, Virtualization/Hypervisors, published 2026-10-14
Flagged for matching Linux kernel, Xen.
In the Linux kernel, the following vulnerability has been resolved:
x86/amd_node: Avoid divide by zero on virtualized systems
On a virtualized system, the number of nodes does not have a relationship to
the number of roots. A Xen PVH dom0 can calculate rootspernode as 0, which
crashes with a divide by zero in:
if (count++ % rootspernode)
because the underlying topology code on Xen ends up making num_nodes
2 and num_roots 1 and the integer division result is 0.
The issue is seen with Xen, but it could affect other systems.
Set rootspernode to 1 in this case. Print a firmware bug when this is
performed for non-virtualized systems.
[ bp: Massage commit message. ]
References:
Containers, published 2026-10-14
Flagged for matching Docker.
Gitea Runner passes workflow-controlled container options into Docker job container configuration while privileged mode is disabled. Host namespace settings, expanded capabilities, and security profile overrides can remain effective despite Privileged being forced false. A workflow author able to run jobs on an affected Docker-backed runner can use these options to access host namespaces and execute commands as root on the runner host, bypassing the intended container isolation.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Use memset_io() to clear QLAFX00 request ring slot
For QLAFX00 the request ring is ioremapped device I/O memory
(ha->iobase + reqqueoff), not DMA-coherent RAM, which is why the rest
of the FX00 path accesses it through memcpytoio() and the wrtreg_*
helpers. __qla2x00allociocbs() however zeroed the producer slot with a
plain memset(). On architectures such as ARM64 a regular memset() may
emit unaligned or block-zeroing instructions (e.g. DC ZVA) that are
invalid on Device memory, leading to a synchronous external abort.
Use memset_io() to clear the slot for QLAFX00, matching the I/O
accessors used elsewhere on this ring. Other adapters keep the plain
memset() on their DMA-coherent rings. The zero-fill is retained for FX00
because its IOCB builders (e.g. qlafx00fxdisciocb()) copy only part of
the entry and rely on the unused tail being pre-zeroed.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
s390/crypto: Fix skcipherwalk return code handling in aess390
The return codes from skcipherwalkvirt() were not properly checked
before entering the processing loops in ecbaescrypt() and ctraescrypt().
If skcipherwalkvirt() fails, the walk structure may be in an undefined
state, and attempting to process data could lead to incorrect behavior
or accessing uninitialized memory.
Add proper return code checking to ensure correct handling of the walk
initialization and walk advance and eventually return to the caller
with that return code.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
exec: docloseonexec() before taking execupdate_lock
docloseonexec() currently happens while holding the execupdate_lock,
which is used in a lot of places that access process state to
synchronize access checks.
I recently added another such use of execupdatelock, causing a
regression.
docloseon_exec() can block waiting for a reply from a filesystem.
That means a hung filesystem can block codepaths that use
execupdatelock; and it also means that a FUSE filesystem which
attempts to inspect the calling process can deadlock.
To avoid such problems, move docloseon_exec() before the
execupdatelock is taken, but after the FD table has been copied if
necessary.
I have looked through all the calls between the old and new position of
the docloseon_exec() call; there seems to be no file descriptor table
access in between.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: skip gfx switchpowerprofile during GPU reset
During resume from GPU reset, the gfx idle work may invoke switchpowerprofile
before the reset completes. This causes the following assert error because the
register access occurs without first releasing the GPU reset semaphore:
[ 1576.768935] CR2: 0000559ea133ead0 CR3: 00000002e6c42000 CR4: 0000000000350ef0
[ 1576.768940] Call Trace:
[ 1576.768944] <TASK>
[ 1576.768953] amdgpudevicerreg+0x21/0x50 [amdgpu]
[ 1576.769158] smumsgv1sendmsg+0x1a4/0x6e0 [amdgpu]
[ 1576.769437] smucmnsendsmcmsgwithparams_ext+0xba/0x120 [amdgpu]
[ 1576.769721] smucmnsendsmcmsgwithparam+0x33/0x40 [amdgpu]
[ 1576.769993] smuv1300setpowerprofile_mode+0x192/0x2b0 [amdgpu]
[ 1576.770267] smubumppowerprofilemode+0x5d/0x80 [amdgpu]
[ 1576.770538] smuswitchpower_profile+0xa4/0xf0 [amdgpu]
[ 1576.770839] amdgpudpmswitchpowerprofile+0x6f/0x90 [amdgpu]
[ 1576.771210] amdgpugfxprofileidlework_handler+0xe9/0x130 [amdgpu]
[ 1576.771460] processonework+0x23e/0x6f0
[ 1576.771491] worker_thread+0x1c4/0x380
[ 1576.771506] kthread+0x10c/0x150
[ 1576.771512] ? __pfxworkerthread+0x10/0x10
[ 1576.771518] ? __pfx_kthread+0x10/0x10
[ 1576.771530] retfromfork+0x314/0x390
[ 1576.771537] ? __pfx_kthread+0x10/0x10
[ 1576.771546] retfromfork_asm+0x1a/0x30
(cherry picked from commit d93b1ff538ce9750c01e0dd0aa62575579c0fc08)
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Guard page-fault worker with runtime PM check
During VM teardown, the VM's runtime PM reference is dropped
asynchronously, allowing the device to autosuspend while stale page
faults belonging to the now-dead VM are still queued. When the
page-fault worker later tries to ack one of these, it calls into
gucctsend_locked() on an already-suspended device, tripping:
Assertion !xepmruntime_suspended(xe) failed!
WARNING at xedevice.c:1267 xedeviceassertmem_access+0x11c/0x140 [xe]
A live VM/exec queue always holds a PM reference while it has
outstanding work, so if the device is suspended at ack time, the
owning context is already gone and the fault is stale.
Take a runtime PM reference across the entire pagefault
queue worker to safely deliver acks for torn-down VMs.
v3:
guard(xepmruntime)(xe) instead of tracking it in the GuC
backend(Matt Brost).
v2:
This prevents the device from autosuspending mid-batch, which would
leave write_only acks written but the end flush skipped, and skip
counter++, desyncing the cadence check.(Himal)
(cherry picked from commit fcc2431d2213dc4d04250c4f1ae87d9c3ae0d455)
[Rodrigo: Added xe_device struct for compatibility while cherry-picking]
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btintelpcie: fix txhandle bounds off-by-one
Valid indices into txq->urbd0s/tfds/bufs are 0..txq->count-1, so
tfd_index == txq->count is already out of range. Change the guard in
btintelpciemsixtxhandle() from '> txq->count' to '>= txq->count'.
This issue was reported by Claude Mythos.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: Fix UDP length overflow with PMTU discover and big MTU
This commit bounds cork->base.fragsize to IPMAXMTU to avoid a
possible overflow of UDP length that triggers a WARN in
udpsetlenshort when setsockopt IPMTU_DISCOVER is set to
IPPMTUDISCPROBE, and a large packet is sent over a netdev with an
unusually large MTU.
Steps to reproduce:
be set to that MTU in ipsetupcork.
set to device MTU (cork->fragsize) in __ipappenddata, rather than
to IPMAXMTU.
IPv4 header). Device MTU allows it (it's only one byte bigger than
IPMAXMTU + IPv4 header, and the device MTU is bigger than that).
16-bit length field and triggers the WARN in udpsetlen_short.
Note: IPPMTUDISCDO with IPv4 is safe, because ipdstmtumaybeforward
always clamps at IPMAXMTU, unlike ip6dstmtumaybeforward.
The Fixes tag points at the first commit where I could reproduce the
overflow with IPv4 and IPPMTUDISCPROBE.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
afunix: Return immediately when manageoob() returns NULL for 0-length buffer.
Fahad Alharbi reported that recv(0, MSG_PEEK) triggers busy-wait
in unixstreamread_generic() if recv() is blocking and the last
skb in the queue is MSG_OOB skb.
In such a situation, TCP returns 0 immediately regardless of
blocking or non-blocking.
Let's follow the behaviour.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/entry: Fix irqsoftmask corruption on replayed interrupt exit
When __replaysoftinterrupts() replays a pending interrupt (e.g.
PACAIRQDEC -> timer_interrupt), it calls the handler directly with a
synthetic ptregs. The DEFINEINTERRUPTHANDLERASYNC wrapper around
each handler calls archinterruptasyncexitprepare() on the way out,
which calls archinterruptexitprepare() -> localirq_disable() ->
archlocalirq_disable(), which does:
irqsoftmaskset(IRQSDISABLED) / 0x1 /
This unconditionally overwrites irqsoftmask with IRQS_DISABLED (0x1),
stripping the IRQSPMIDISABLED (0x2) bit. The result is that
irqsoftmask is 0x1 instead of IRQSALLDISABLED (0x3) when the
handler returns to __replaysoftinterrupts().
For a normally-taken interrupt this is harmless: the next interrupt
always enters through archinterruptenter_prepare() which
unconditionally sets irqsoftmask to IRQSALLDISABLED. But during
replay, next_interrupt() is called directly between replayed handlers
without going back through archinterruptenter_prepare(), so the
stripped bit is never restored. next_interrupt() then fires a WARNING:
WARNING: arch/powerpc/kernel/irq_64.c:75
WARNON(irqsoftmaskreturn() != IRQSALLDISABLED)
The warning was observed early in boot on a POWER10 pseries guest
during kmemcacheinit_late(), where a spinlock release triggers
interrupt replay that processes a pending timer interrupt.
Debugger state confirming the bug:
Before timer_interrupt(®s):
irqsoftmask = 0x3 (IRQSALLDISABLED) correct
irqhappened = 0x41 (HARDDIS|REPLAYING) correct
After timer_interrupt(®s) returns:
irqsoftmask = 0x1 (IRQS_DISABLED) WRONG - PMI bit stripped
irq_happened = 0x41 unchanged
The fix is to replace localirqdisable() with hardirqdisable().
hardirqdisable() is the right primitive here for two reasons:
setting the soft mask to 0x3 (both IRQSDISABLED and IRQSPMI_DISABLED),
which preserves the PMI bit and fixes the WARNING. The additional
work it does (__hardirqdisable(), PACAIRQHARD_DIS |=) is
redundant but safe since both are already set at this point in the
exit path; the tracehardirqsoff() inside is guarded by
if (!archirqsdisabled_flags(flags)) so it will not double-fire.
archlocalirq_disable() -> __hardirqdisable(), which clears
MSR[EE] in hardware. This is exactly correct: PPC32 has no soft-mask
PACA mechanism, so the hardware disable is the right way to satisfy
irqentry_exit()'s requirement. This also fixes a build error on PPC32
where irqsoftmaskset() is only defined under CONFIGPPC64:
arch/powerpc/include/asm/entry-common.h:273: error: implicit
declaration of function 'irqsoftmask_set'
Using hardirqdisable() requires no #ifdef and is consistent with
how the rest of the entry code (e.g. entry-common.h:463) handles the
same PPC32/PPC64 split.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown
In gpiosecondaryfwnodeinit(), acpibusfinddevicebyname() returns a
device reference, but the local dev variable is declared with
__free(put_device), dropping the reference at the end of each iteration.
Meanwhile, devmaddactionorreset() saves the dev pointer for
gpiosecondaryunset() without incrementing its reference count, which
could lead to a use-after-free during driver teardown if the device is
released in the interim.
Acquire an explicit device reference with get_device() when registering
the devres action, and drop it with put_device() inside
gpiosecondaryunset().
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
locking/lockdep: Invalidate stale class_cache entries for zapped classes
syzbot reported a lockdep splat hitting DEBUGLOCKSWARN_ON(1) in
hlockclass() due to an invalid classidx:
WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203
Workqueue: wg-crypt-wg0 wgpackettx_worker
RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]
RIP: 0010:checkwaitcontext kernel/locking/lockdep.c:4870 [inline]
RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203
Call Trace:
<IRQ>
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886
rawspin_lock+0x2e/0x40 kernel/locking/spinlock.c:173
tcptsqhandler+0x29/0x200 net/ipv4/tcp_output.c:1291
tcptsqworkfn+0x384/0x410 net/ipv4/tcp_output.c:1325
...
When a lock class is zapped (e.g. during module unload or key
unregistration), zap_class() clears the class's bit in
lockclassesin_use and removes it from the class hash table.
However, existing lockdep_map instances embedded in data structures
may still retain a pointer to the zapped class in their class_cache[]
array.
When __lock_acquire() subsequently runs on such a lock, it finds
lock->classcache[subclass] != NULL, skipping registerlock_class()
and assigning hlock->class_idx to the index of the zapped class. When
checkwaitcontext() or hlockclass() inspects the heldlock, it finds
!testbit(classidx, lockclassesin_use) and warns. Furthermore, if
the zapped slot is subsequently re-allocated to an unrelated lock key,
the stale class_cache entry would erroneously match the unrelated
class (ABA issue).
Add lockclasscacheisvalid() to validate that the cached class is
within lockclasses bounds, still allocated in lockclassesinuse
(using uninstrumented archtestbit() in __always_inline context so it
is safe in noinstr contexts like matchheldlock()), and that
class->key matches the expected subkey (taking lockdepsetsubclass()
overrides into account). Also use READONCE()/WRITEONCE() when
accessing class_cache[]. If the entry is invalid or stale, fall back
to registerlockclass() / lookuplock_class().
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
net: icmp: avoid invalid transport header access in icmp_send tracepoint
syzbot reported a WARNING triggered by DEBUGNETWARNONONCE():
WARNING: at skbtransportheader include/linux/skbuff.h:3087 [inline]
WARNING: at udp_hdr include/linux/udp.h:23 [inline]
WARNING: at dotraceeventraweventicmpsend include/trace/events/icmp.h:30 [inline]
WARNING: at traceeventraweventicmp_send+0x48c/0x6ec include/trace/events/icmp.h:11
Call trace:
skbtransportheader include/linux/skbuff.h:3087 [inline]
udp_hdr include/linux/udp.h:23 [inline]
dotraceeventraweventicmpsend include/trace/events/icmp.h:30 [inline]
traceeventraweventicmp_send+0x48c/0x6ec include/trace/events/icmp.h:11
__traceitericmpsend include/trace/events/icmp.h:11 [inline]
__dotraceicmp_send include/trace/events/icmp.h:11 [inline]
traceicmpsend+0x320/0x49c include/trace/events/icmp.h:11
__icmp_send+0xcfc/0x11d8 net/ipv4/icmp.c:1013
ipv4senddest_unreach net/ipv4/route.c:1280 [inline]
ipv4linkfailure+0x57c/0x8dc net/ipv4/route.c:1287
dstlinkfailure include/net/dst.h:438 [inline]
vtitunnelxmit+0xe40/0x17a4 net/ipv4/ip_vti.c:307
TPfastassign() unconditionally calls udp_hdr(skb) before checking
whether the packet is UDP. Furthermore, __icmp_send() can be invoked
from paths (e.g., link failures, ARP errors, forwarding, AF_PACKET)
where skb->transport_header was never initialized (~0U).
Under CONFIGDEBUGNET=y, calling skbtransportheader(skb) triggers
DEBUGNETWARNONONCE(!skbtransportheaderwasset(skb)).
Fix this by:
to safely fetch the UDP header without assuming transport_header is set.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
s390/boot: Avoid IPL parameter append past command line
A command line may occupy all but the terminating byte of
COMMANDLINESIZE. In that case appendiplblock_parm() passes a zero size
to the IPL parameter conversion helpers and points the destination one
byte past earlycommandline. The helpers subtract one from the unsigned
size and write the converted parameter outside the command line buffer.
Convert the IPL parameter in the command line parsing buffer first. A
parameter beginning with '=' can then replace the existing command line
regardless of its length, while other parameters are appended only when
space remains.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: Fix a NULL vs ERRPTR() bug in virtiogpuuserframebuffer_create()
Smatch complains that returning a NULL here will lead to a NULL pointer
dereference in drmmodeaddfb2(). Return an error pointer instead.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix missing iov bounds check in parseposixsids()
In parseposixsids(), sidsbuf_end is calculated using the server-supplied
out_len without being validated against the actual length of the received
iov (iov_len).
If a server provides an inflated outlen, sidsbufend will point past the
end of the iov. This defeats the bounds guards in posixinfosid_size(),
allowing out-of-bounds reads into adjacent kernel memory.
Fix this by rejecting responses where the calculated sidsbuf_end would
exceed the received iov boundaries or cause pointer wraparound.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: avoid WARN in setbitratemask when sdata not in driver
ieee80211setbitrate_mask() checks if the interface is running via
ieee80211sdatarunning(), but it does not check if the interface is
still present in the driver.
When sdata is running but IEEE80211SDATAIN_DRIVER is not set, the
call reaches drvsetbitrate_mask() in driver-ops.h which hits
wlan1: Failed check-sdata-in-driver check, flags: 0x0
WARNING: net/mac80211/driver-ops.h:884 at drvsetbitrate_mask
Syzkaller triggers this via wext SIOCSIWRATE ioctl. The Call Trace shows
wextioctldispatch() in wext-core.c dispatching the ioctl, calling
ioctlstandardcall() for SIOCSIWRATE, which calls cfg80211wextsiwrate()
in wext-compat.c. That builds a bitrate mask and calls
rdevsetbitratemask() which ends up in ieee80211setbitratemask() in
cfg.c. The interface is marked running via SDATASTATERUNNING but
flags is 0, so checksdatain_driver() fails.
When the interface is being torn down, or when wext ioctl is issued
during interface bringup before drvaddinterface() sets IN_DRIVER, the
running check passes while IN_DRIVER is clear.
Check IEEE80211SDATAINDRIVER in ieee80211setbitratemask() before
calling the driver, returning -ENETDOWN. This avoids the WARN_ONCE in
driver-ops.h and matches other cfg.c operations that bail early when not
in driver.
This change should be safe because wiphy mutex is held in
cfg80211wextsiwrate() via guard(wiphy), and IN_DRIVER is set/cleared
under RTNL and wiphy paths in drvaddinterface() and
drvremoveinterface() in driver-ops.c, so the check is race-free
against driver add/remove. Returning -ENETDOWN is the same error other
not-running paths use and does not introduce new locking.
[also add second syzbot report]
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
wifi: rsi: fix heap OOB write on key removal
When a key is removed (data == NULL), rsihalload_key() runs:
memset(&setkey[FRAMEDESCSZ], 0, framelen - FRAMEDESCSZ);
setkey is a struct rsiset_key *, so the subscript is scaled by
sizeof(struct rsisetkey) (160 bytes): &setkey[FRAMEDESC_SZ] is
skb->data + 2560, and the memset writes 144 zero bytes starting
2.4KB past the end of the 160-byte skb data buffer, corrupting
unrelated heap objects. The intended byte offset would have been
(u8 *)setkey + FRAMEDESC_SZ.
The write fires on every DISABLE_KEY callback, so plain disconnects,
roams and interface teardowns trigger it on real networks.
The memset is redundant: the whole buffer is zeroed right after
allocation, so the frame sent to the device is byte-identical
without it. Drop the else branch; normal operation is unaffected.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
watchdog: rzv2h: Avoid division by zero
clkgetrate() could return 0. Avoid a division by zero panic.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
watchdog: rtd119x: Avoid division by zero
clkgetrate() could return 0. Avoid a division by zero panic.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
watchdog: da9063: fix suspend/resume handling of HW_RUNNING watchdog
da9063wdtsuspend() and da9063wdtresume() only check watchdog_active(),
when the watchdog is left running by the driver sets
WDOGHWRUNNING in da9063wdtprobe() but userspace never opens the
device, so WDOGACTIVE remains cleared, the wdtdisable() will not be
executed in da9063wdtsuspend. In this case, the suspend callback is
a no-op and the watchdog keeps counting during system suspend,
leading to an unexpected system reset.
Check WDOGHWRUNNING and wdd，can fix this issue.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
power: sequencing: fix NULL-pointer dereference in pwrseqdeviceregister()
If devsetname() fails in pwrseqdeviceregister(), we jump to the
errputpwrseq label before initializing pwrseq->targets.
pwrseq_release() will try to iterate over targets unconditionally and
subsequently dereference an invalid pointer. Move the call to
devsetname() after the list head is initialized.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
power: sequencing: fix NULL-pointer dereference in pwrsequnitnew()
If memory allocation fails in pwrsequnitsetupdeps(), pwrsequnit_put()
is called to release the partially initialized unit. However, we've
never initialized unit->list and pwrsequnitrelease() will
unconditionally call list_del() on it. Initialize unit->list right after
allocating the unit struct.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
selinux: always fill AVC decision in avchasperm_noaudit()
avchasperm_noaudit() is documented to return a copy of the access
decision in @avd, but its early return for an empty requested permission
set leaves the buffer untouched. All callers pass an uninitialized
stack variable and afterwards feed it to avc_audit(), and the inode hook
even stores it in the per-task decision cache.
Fill in a deny-all, audit-all decision, similar to avd_init(), so every
caller receives a defined value at no cost on the hot path.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
memcg: avoid charging the root memcg from objcgroupcharge_pages()
objcgroupcharge_pages() resolves the objcg to its memcg and calls
trychargememcg(), which does not short circuit the root memcg. That
memcg can be the root memcg: objcgroupis_root() reflects the memcg the
objcg was created for and is never updated, while memcgreparentobjcgs()
does redirect objcg->memcg to the parent on rmdir. An objcg of a dying
child of root therefore passes every objcgroupis_root() filter but
resolves to the root memcg.
Folios keep the objcg they were charged with, so this is easy to reach
through zswap: allocate anon memory in a cgroup, move the task out, remove
the cgroup, then write to the root cgroup's memory.reclaim. The reclaimed
folios are charged through the reparented objcg and end up in
refill_stock() with the root memcg:
WARNING: mm/memcontrol.c:2198 at refill_stock+0x644/0x940
refill_stock+0x644/0x940
trychargememcg+0x12d6/0x1570
__objcgroupcharge+0x35/0xf0
objcgroupcharge+0x1de/0x210
objcgroupcharge_zswap+0x83/0x270
zswap_store+0x1620/0x2000
swap_writeout+0x94c/0x14c0
shrinkfoliolist+0x3388/0x52b0
[...]
trytofreememcgroup_pages+0x30d/0x830
userproactivereclaim+0x504/0x840
memory_reclaim+0x1f/0x30
Beyond the warning, the charge is asymmetric: objcgroupuncharge_pages()
skips refill_stock() for the root memcg, so the root's page counter grows
and is never uncharged. It is not user visible, since memory.current is
not exposed on the root, but it is a leak.
Use try_charge(), which returns early for the root memcg, restoring the
symmetry with objcgroupuncharge_pages().
The above sequence was scripted into a standalone reproducer (zswap on,
swap on a virtio disk, 512MB of anon memory faulted in inside a child of
the root cgroup, the task then migrated to the root cgroup, the child
removed, followed by "echo 600M swappiness=max > memory.reclaim" on the
root) and run in a CONFIGDEBUGVM=y VM. It reproduces the splat on the
first zswap store of a reparented folio, with the same call chain as the
report. With this patch applied the splat is gone while the zswap store
count over the run is unchanged, so the same path is still exercised.
cgroup selftests testzswap, testkmem and test_memcontrol show no new
failures.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
soc: samsung: exynos-pmu: fix use-after-free of interrupt generator node
The setupcpuhpand_cpuidle() parses the device tree node for the
interrupt generation block via ofparsephandle() and decrements its
reference count using ofnodeput() immediately after fetching the resource
address. However, later the intrgennode pointer is passed into
ofsysconregister_regmap().
Fix this by declaring intrgennode with __free() and removing
ofnodeput().
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: k3-udma-glue: fix NULL dereference in k3udmagluereleaserx_chn()
If devmkcalloc() for rxchn->flows fails in a channel request function,
the error path calls k3udmagluereleaserx_chn(), which dereferences
the NULL rxchn->flows pointer in k3udmagluereleaserxflow().
Skip the flow release loop in k3udmagluereleaserx_chn() when
rx_chn->flows is not allocated.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
net: xfrm: reject unrepresentable espintcp transport headers
ESP-in-TCP can hand xfrm packets whose transport header offset no longer
fits after the stream parser trims the TCP envelope. The plain transport
header reset truncates that offset and triggers the skb warning path.
Use the careful transport-header helper and drop the skb through the
existing XFRM error path when the offset cannot be represented.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
sched/core: Avoid false migration warning for proxy donors
Proxy execution can move a blocked donor's scheduling context to the
lock owner's CPU even when the donor is migration-disabled. The donor
does not execute there, and its original execution CPU remains recorded
in wake_cpu.
settaskcpu() warns unconditionally for migration-disabled tasks, so a
subsequent proxy migration or the wakeup path returning the donor home
triggers a false positive: moving a blocked scheduling context does not
violate the migration-disabled execution context.
For example, creating a mutex owner on CPU1 and a migration-disabled
waiter on CPU0 can trigger the following warning:
proxymigraterepro: donor blocking on CPU0 with migration disabled
proxymigraterepro: donor moved from CPU0 to CPU1
WARNING: kernel/sched/core.c:3389 at settaskcpu+0x1d3/0x280
...
Call Trace:
trytowake_up+0x43f/0x780
__mutexunlockslowpath+0x330/0x540
ownerfn+0x9f/0xc0 [proxymigrate_repro]
...
proxymigraterepro: donor woke on CPU0, task_cpu=0
proxymigraterepro: completed
Exclude blocked proxy donors from the warning. The proxy wakeup path
restores an executable placement before clearing the blocked state.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
dropmonitor: fix out-of-bounds write in resetpercpudata()
In resetpercpu_data(), al is computed as:
al = sizeof(struct netdmalert_msg);
al += dmhitlimit * sizeof(struct netdmdrop_point);
al += sizeof(struct nlattr);
skb = genlmsgnew(al, GFPKERNEL);
...
nla = nlareserve(skb, NLAUNSPEC, sizeof(struct netdmalert_msg));
...
msg = nla_data(nla);
memset(msg, 0, al);
Because al includes sizeof(struct nlattr) (the 4-byte attribute header),
genlmsg_new() allocates al bytes of tailroom starting at nla.
However, msg points to nla_data(nla), which is located
sizeof(struct nlattr) bytes past nla. Calling memset(msg, 0, al)
therefore writes al bytes starting from msg, exceeding the allocated
buffer by sizeof(struct nlattr) (4 bytes) and corrupting
skbsharedinfo.
Fix this by letting al represent only the payload length, allocating
the skb with genlmsgnew(nlatotalsize(al), GFPKERNEL), and zeroing
al bytes from msg.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: follow SMB2 session expiration semantics
ksmbdsessionregister() destroys valid sessions after ten seconds of
inactivity whenever a client starts another SessionSetup exchange. This
confuses Session.IdleTime with Session.ExpirationTime. Windows can create
additional authenticated sessions on an existing connection, so deleting
the older session invalidates its tree connects and makes mapped drives
fail with STATUSNETWORKNAME_DELETED.
The session expiration rules require the server to change a valid session
to expired only after its credential expiration time passes. A valid or
expired session otherwise keeps its connection from being scavenged.
Connections that have not negotiated a dialect, have no sessions, or have
only InProgress sessions are disconnected after an implementation-specific
timeout. Use the Windows-compatible 45 second value and run the expiration
check periodically for both TCP and SMB Direct.
Keep zero as an infinite credential expiration time, and count each
Valid-to-Expired transition. Set expired sessions to InProgress when they
reauthenticate. If authentication fails, remove the session from the
global and per-connection tables immediately, including SMB3 multichannel
connections.
Retain protection against abandoned SessionId-zero exchanges by allowing
only one InProgress authentication per connection. Additional exchanges
fail with STATUSINSUFFICIENTRESOURCES, and stale InProgress sessions are
reaped after the same 45 second setup timeout. This bounds the original
unauthenticated memory-exhaustion path without evicting established
sessions.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: require a peer station for TDLS setup confirm
It's nonsense for the setup confirm to go to station that
doesn't even exist, and it hits a warning when building
the frame:
WARNONONCE(!sta || !ap_sta)
Only accept WLANTDLSSETUP_CONFIRM when the station is
already there as a TDLS station. Need to copy the call
to ieee80211tdlsprepmgmtpacket() since the existing
WLANTDLSDISCOVERY_REQUEST already falls through to it.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown
On ifup, APVLAN interfaces get cryptotxtailroomneeded_cnt from
the AP interface, but it's never decremented again unless the AP is
also brought down. Thus, bringing the same AP_VLAN up again will
increment the counter again and eventually hit the sanity check:
WARNONONCE(sdata->cryptotxtailroomneededcnt !=
master->cryptotxtailroomneededcnt);
Reset it on ifdown to avoid that.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211_hwsim: don't hand frames to mac80211 while stopping
The code checks ->started for frames coming from wmediumd, but the
radio can be stopped after the check and before frame delivery,
causing mac80211 to hit the WARN_ON(!local->started).
Expand the mutex for this case and synchronise against it when the
radio is stopped to avoid being able to hit the warning with hwsim.
Drop the error print that would've complicated the error path, it
only triggers for allocation failures (already noisy) and malformed
frames anyway.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: undo netns switch if renaming the wiphy fails
Once all the interfaces have been moved, cfg80211switchnetns()
moves the wiphy itself by setting its network namespace and then
renaming it, which makes sysfs move it. The rename can fail (but
only on allocation failures), leaving things mixed up and hitting
the warning there.
Ignoring it isn't great, undo the move and let the change fail
in this case. If undo fails then WARN, then things would again
be stuck in two different network namespaces.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't warn when an IBSS has no channel to scan
ieee80211requestibss_scan() warns when regulatory leaves no
allowed channel, but that can happen as the regdomain can change
while IBSS is operating, and it can continue to operate briefly
during the 60s grace period until it's shut down.
Just remove the warning in this case.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path
mwifiexpcierequest_irq() registers each MSI-X vector with a per-index
devid (&card->msixctx[i]). On a request_irq() failure the cleanup loop
"for (j = 0; j < i; j++)" frees msix_entries[j].vector but passes the
failed index's &card->msixctx[i] as the devid. free_irq() matches on
(irq, dev_id), so it fails to find the action registered with
&card->msix_ctx[j]: the already-requested IRQ j is not freed (leaked) and
freeirq() warns about freeing a non-existent IRQ. Use &card->msixctx[j].
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: codel: bound the dropping loop per dequeue call
The CoDel control law schedules the next drop one interval/sqrt(count)
after the previous drop, using the configured interval
(codel_params.interval). For very small intervals the scheduled step
rounds down to zero, so the dropping loop in codel_dequeue() never
advances and drains the entire backlog under the qdisc lock in one
call - an unprivileged user can trigger a soft lockup this way.
Fix in the shared codel code used by both codel and fq_codel:
always moves forward.
per codeldequeue() call, resyncing dropnext to now when the cap
is hit: the catch-up owed to the loop grows with the idle gap and
the backlog, which no interval threshold can bound. This is a
deliberate behaviour change after long idle gaps.
The cap applies to fq_codel (4b549a2ef4be) and the mac80211 TXQ path
(fixed interval, cap only).
The target sojourn delay (codel_params.target) is not validated: it
does not feed the control law, so a sub-tick value is aggressive
rather than deadlock-prone.
Conditions to recreate the bug:
soft-lockups (watchdog: BUG: soft lockup) while one
codel_dequeue() call drops the backlog under the qdisc lock
no soft lockup
Testing: claim reproducer and interval 2us/3us variants run clean;
tdc qdisc category passes (see the selftests patch).
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb: 6fire: Avoid embedded URBs
The USB 6fire driver uses URBs embedded in different structs for PCM,
MIDI and communication, and this is basically a buggy implementation
nowadays; since a URB is managed with a refcount, this may lead to a
UAF when the URB is released asynchronously.
For addressing the problem, this patch converts those embedded URBs to
ones that are properly allocated via usballocurb(). The
pcmurb.packets[] is gone, as it's allocated by usballoc_urb(), hence
it's found in urb.isoframedesc[] instead.
The conversions are rather straightforward; each embedded struct urb
is changed to a pointer, and its callers are updated accordingly.
The resource for those structs are released in the common destructor
functions (usb6firecommfree(), etc), which are called at both the
init error path and the disconnect.
No functional changes, only compile-tested.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/efa: Keep EQ resources alive while IRQ is registered
The completion IRQ handler accesses the EQ state and DMA buffer. Its IRQ was
registered before that state was initialized, while teardown released the
buffer before free_irq() synchronized the handler.
Initialize the EQ without arming it, register the IRQ, and then arm it.
Reverse the resource order during teardown by freeing the IRQ before
destroying the EQ.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/efa: Keep admin queues alive while IRQ is registered
The management IRQ handler accesses both the admin completion queue and the
async event queue. The driver registered the IRQ before constructing these
queues and destroyed them before freeing the IRQ, so the handler's lifetime
was not contained by the resources it accesses.
Initialize the queues with interrupts masked, request the IRQ, and then
switch to interrupt mode. On removal, reset the device and free the IRQ
before destroying the queues. Also reset the device before destroying the
queues if IRQ registration fails, because the device already has their DMA
addresses.
References:
Linux Kernel, published 2026-10-14
Flagged for matching Linux kernel.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/uverbs: Fix mmaplock/disassociationlock circular dependency
Commit 51976c6cd786 ("RDMA/core: Provide rdmausermmap_disassociate()
to disassociate mmap pages") introduced disassociation_lock to protect
new mmap registrations against uverbsusermmap_disassociate(), but
created an ABBA deadlock:
Thread A (mmap / fork):
mmaplock -> disassociationlock
Thread B (disassociate):
disassociationlock -> mmaplock
Fix by removing disassociation_lock entirely and using the pre-existing
hwdestroyrwsem instead. hwdestroyrwsem already provides the same
protection: rdmaumapopen() and ibuverbsmmap() both use
downreadtrylock() before registering a new VMA, so holding hwdestroyrwsem
in uverbsusermmap_disassociate() is sufficient to block new registrations.
trylock is used in both mmap paths (not blocking down_read) because
mmaplock is already held on entry, and uverbsusermmapdisassociate()
acquires mmap_lock internally — a blocking read would recreate the same
deadlock.
The only caller that was not taking hwdestroyrwsem for write was
rdmausermmap_disassociate(). Fix it to take the rwsem per-ufile while
iterating under listsmutex. This is safe because ibuverbs_close()
releases hwdestroyrwsem entirely before acquiring lists_mutex, so the
two locks are never held simultaneously.
lockdep warning:
[ 776.654252] ======================================================
[ 776.655214] WARNING: possible circular locking dependency detected
[ 776.656167] 6.18.0for-upstreamdebug94e244d9ccab #1 Not tainted
[ 776.657114] ------------------------------------------------------
[ 776.658087] devlink/14824 is trying to acquire lock:
[ 776.658879] ffff88811170c800 (&mm->mmaplock){++++}-{4:4}, at: uverbsusermmapdisassociate+0x168/0x780 [ib_uverbs]
[ 776.660479]
[ 776.660479] but task is already holding lock:
[ 776.661460] ffff888142d92b08 (&file->disassociationlock){+.+.}-{4:4}, at: uverbsusermmapdisassociate+0x39/0x780 [ib_uverbs]
[ 776.663177]
[ 776.663177] which lock already depends on the new lock.
[ 776.663177]
[ 776.664525]
[ 776.664525] the existing dependency chain (in reverse order) is:
[ 776.665724]
[ 776.665724] -> #2 (&file->disassociation_lock){+.+.}-{4:4}:
[ 776.666887] __mutex_lock+0x16d/0x2330
[ 776.667633] rdmaumapopen+0x129/0x280 [ib_uverbs]
[ 776.668489] dup_mmap+0xa40/0x1790
[ 776.669170] copy_process+0x5dd2/0x6170
[ 776.669933] kernel_clone+0xb6/0x610
[ 776.670636] __dosysclone+0xb5/0xf0
[ 776.671354] dosyscall64+0x70/0x12e0
[ 776.672083] entrySYSCALL64afterhwframe+0x4b/0x53
[ 776.672940]
[ 776.672940] -> #1 (&mm->mmap_lock/1){+.+.}-{4:4}:
[ 776.673985] downwritenested+0x90/0x1e0
[ 776.674751] dup_mmap+0x201/0x1790
[ 776.675448] copy_process+0x5dd2/0x6170
[ 776.676180] kernel_clone+0xb6/0x610
[ 776.676904] __dosysclone+0xb5/0xf0
[ 776.677615] dosyscall64+0x70/0x12e0
[ 776.678351] entrySYSCALL64afterhwframe+0x4b/0x53
[ 776.679239]
[ 776.679239] -> #0 (&mm->mmap_lock){++++}-{4:4}:
[ 776.680253] __lock_acquire+0x18c6/0x2ec0
[ 776.681018] lock_acquire+0x10e/0x2e0
[ 776.681742] down_read+0x95/0x430
[ 776.682395] uverbsusermmapdisassociate+0x168/0x780 [ibuverbs]
[ 776.683436] uverbsdestroyufilehw+0x1ae/0x270 [ibuverbs]
[ 776.684416] ibuverbsremoveone+0x22b/0x420 [ibuverbs]
[ 776.685371] removeclientcontext+0xa6/0xf0 [ib_core]
[ 776.686342] disabledevice+0x12b/0x240 [ibcore]
[ 776.687249] __ibunregisterdevice+0x269/0x460 [ib_core]
[ 776.688233] ibunregisterdevice+0x21/0x30 [ib_core]
[ 776.689140] mlx5rremove+0xd0/0x170 [mlx5ib]
[ 776.689999] devicereleasedriver_internal+0x3b2/0x5
---truncated---
References:
Remote Access / Networking, published 2026-10-14
Flagged for matching OpenVPN.
The fix for CVE-2026-12996 was incomplete. A use-after-free in OpenVPN 2.6.0 through 2.6.22 and 2.7_alpha1 through 2.7.7 allows remote authenticated peers to potentially cause a denial of service or leak memory via crafted packets during TLS session promotion or expiry.
References: