🚨 CVE-2026-64423
In the Linux kernel, the following vulnerability has been resolved:

ipv4: igmp: remove multicast group from hash table on device destruction

When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through
the multicast list and calls ip_ma_put() on each membership, scheduling
them for RCU reclamation. However, they are not unlinked from the device's
multicast hash table (mc_hash).

Since the device remains published in dev->ip_ptr until after
ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash
can still locate and access the multicast group after its refcount is
decremented. If the RCU callback runs and frees the group while a reader is
accessing it, a use-after-free occurs.

Fix this by unlinking the multicast group from mc_hash using
ip_mc_hash_remove() before scheduling it for reclamation.

BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0
Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276

Call Trace:
<IRQ>
dump_stack_lvl+0x67/0x90
print_report+0x175/0x7c0
kasan_report+0x147/0x180
ip_check_mc_rcu+0x149/0x3f0
udp_v4_early_demux+0x36d/0x12d0
ip_rcv_finish_core+0xb8b/0x1390
ip_rcv_finish+0x54/0x120
NF_HOOK+0x213/0x2b0
__netif_receive_skb+0x126/0x340
process_backlog+0x4f2/0xf00
__napi_poll+0x92/0x2c0
net_rx_action+0x583/0xc60
handle_softirqs+0x236/0x7f0
do_softirq+0x57/0x80
</IRQ>

Allocated by task 2239:
kasan_save_track+0x3e/0x80
__kasan_kmalloc+0x72/0x90
____ip_mc_inc_group+0x31a/0xa40
__ip_mc_join_group+0x334/0x3f0
do_ip_setsockopt+0x16fa/0x2010
ip_setsockopt+0x3f/0x90
do_sock_setsockopt+0x1ad/0x300

Freed by task 0:
kasan_save_track+0x3e/0x80
kasan_save_free_info+0x40/0x50
__kasan_slab_free+0x3a/0x60
__rcu_free_sheaf_prepare+0xd4/0x220
rcu_free_sheaf+0x36/0x190
rcu_core+0x8d9/0x12f0
handle_softirqs+0x236/0x7f0

🎖@cveNotify

🚨 CVE-2026-64426
In the Linux kernel, the following vulnerability has been resolved:

io_uring/nop: fix file reference leak with IOSQE_FIXED_FILE

NOP file-acquisition support choses between a fixed (registered) file and
a normal fget()'d file based on its own IORING_NOP_FIXED_FILE flag in
sqe->nop_flags. However, a request's REQ_F_FIXED_FILE is set
independently from the generic IOSQE_FIXED_FILE sqe flag during request
init, before the issue handler runs.

If a NOP is submitted with IOSQE_FIXED_FILE set (so REQ_F_FIXED_FILE is
set) but without IORING_NOP_FIXED_FILE, io_nop() takes the normal path
and grabs a real reference via io_file_get_normal(). On completion,
io_put_file() only drops the reference when REQ_F_FIXED_FILE is clear,
so the fget()'d file is never released and leaks:

BUG: memory leak
unreferenced object 0xffff88800f42c240 (size 176):
kmem_cache_alloc_noprof+0x358/0x440
alloc_empty_file+0x57/0x180
path_openat+0x44/0x1e50
do_file_open+0x121/0x200
do_sys_openat2+0xa7/0x150
__x64_sys_openat+0x82/0xf0

Decide between fixed and normal file acquisition from REQ_F_FIXED_FILE,
the same way io_assign_file() does for every other opcode, and fold
IORING_NOP_FIXED_FILE into REQ_F_FIXED_FILE at prep time.

🎖@cveNotify

🚨 CVE-2026-64427
In the Linux kernel, the following vulnerability has been resolved:

HID: logitech-dj: Fix maxfield check in DJ short report validation

Commit b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT
related user initiated OOB write") added validation for the DJ short
output report, but the error path dereferences rep->field[0] even when
rep->maxfield is zero.

Commit 8b9a097eb2fc ("HID: logitech-dj: fix wrong detection of bad
DJ_SHORT output report") made the check conditional on rep being present,
but a crafted descriptor can still create report ID 0x20 with only padding
output items. hid-core registers the report, ignores the padding field,
and leaves rep->maxfield as zero.

In that case the validation enters the rep->maxfield < 1 branch and then
dereferences rep->field[0]->report_count while printing the error message,
causing a NULL pointer dereference during probe. This is reproducible with
uhid by emulating a Logitech receiver with a padding-only DJ short output
report:

BUG: KASAN: null-ptr-deref in logi_dj_probe+0xb1/0x754 [hid_logitech_dj]
Read of size 4 at addr 0000000000000028 by task kworker/4:1/129
...
Call Trace:
logi_dj_probe+0xb1/0x754 [hid_logitech_dj]
hid_device_probe+0x329/0x3f0 [hid]
really_probe+0x162/0x570
__device_attach+0x137/0x2c0
bus_probe_device+0x38/0xc0
device_add+0xa56/0xce0
hid_add_device+0x19c/0x280 [hid]
uhid_device_add_worker+0x2c/0xb0 [uhid]

Reject the zero-field report before printing the field report_count.

🎖@cveNotify

🚨 CVE-2026-64428
In the Linux kernel, the following vulnerability has been resolved:

gpio: sch: use raw_spinlock_t in the irq startup path

sch_irq_unmask() enables the GPIO IRQ and then updates the controller
state through sch_irq_mask_unmask(), which takes sch->lock with
spin_lock_irqsave(). The callback can be reached from irq_startup()
while setting up a requested IRQ. That path is not sleepable, but on
PREEMPT_RT a regular spinlock_t becomes a sleeping lock.

This issue was found by our static analysis tool and then manually
reviewed against the current tree.

The grounded PoC kept the request_threaded_irq() -> __setup_irq() ->
irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and
used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported:

BUG: sleeping function called from invalid context
hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]
sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]
sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv]
__setup_irq.constprop.0+0xd/0x30 [vuln_msv]

Convert the SCH controller lock to raw_spinlock_t. The same lock is
also used by the GPIO direction and value callbacks, but those critical
sections only update MMIO-backed GPIO registers and do not contain
sleepable operations. Keeping this register lock non-sleeping is
therefore appropriate for the irqchip callbacks and does not change the
GPIO-side locking contract.

🎖@cveNotify

🚨 CVE-2026-56718
AJCloud AJY IPC firmware prior to version 01.10715.11.37 contains a path traversal vulnerability in the jdbhttpd web service that allows unauthenticated remote attackers to read arbitrary files with root privileges by supplying path traversal sequences in the HTTP request URI. Attackers can send crafted HTTP requests to port 80 without authentication to access sensitive files including cleartext RTSP credentials, Wi-Fi SSID and pre-shared key, device serial number, and cloud binding parameters.

🎖@cveNotify

🚨 CVE-2026-12894
A flaw was found in the Qute template engine, which is used by Quarkus to generate dynamic content like HTML pages or emails. The issue exists in the component responsible for looking up data values (ReflectionValueResolver), which fails to properly block access to sensitive Java internal functions when processing certain data types like Enums. An attacker who can provide or influence the template text can exploit this bypass to take control of the server by executing unauthorized commands.

🎖@cveNotify

🚨 CVE-2026-13732
A flaw was found in GDB's STABS debug format parser. The
read_member_functions() function in gdb/stabsread.c contains a linked
list removal bug in the code that separates destructor and non-destructor
member functions of C++ classes. The bug causes the destructor entries to
remain in the main function list while the list length counter is
decremented, resulting in an out-of-bounds write when the function list
is copied to its final allocated array. An attacker can craft an ELF
binary with malicious .stab and .stabstr sections that triggers this
out-of-bounds write when a user opens the file in GDB and performs any
symbol-inspection operation such as setting a breakpoint. The inferior
process does not need to be executed. Under controlled conditions, this
was demonstrated to achieve execution of arbitrary commands within the
GDB process.

🎖@cveNotify

🚨 CVE-2026-73752
An unauthenticated arbitrary file write vulnerability exists in an API endpoint of AOS-CX. Successful exploitation of this vulnerability allows an attacker to write arbitrary files to the underlying operating system, which could lead to remote code execution.

🎖@cveNotify

🚨 CVE-2026-73754
Denial-of-service vulnerabilities exist in the command line interface of AOS-CX. Successful exploitation could allow an authenticated user to disrupt the normal operation of a vulnerable system.

🎖@cveNotify

🚨 CVE-2026-73755
A privilege escalation vulnerability exists in the API endpoint of AOS-CX. Successful exploitation could allow an authenticated low-privilege operator user, after a required user action, to access sensitive information from the vulnerable system.

🎖@cveNotify

🚨 CVE-2026-73756
A vulnerability in an API endpoint of AOS-CX could allow a remote unauthenticated attacker to obtain sensitive information via a man-in-the-middle attack. Successful exploitation allows an attacker to retrieve data which could be used to further compromise the confidentiality of the affected system.

🎖@cveNotify

🚨 CVE-2026-73757
A vulnerability in the web-based management interface of AOS-CX could allow an authenticated remote attacker to conduct a server-side request forgery (SSRF) attack. A successful exploit allows an attacker to enumerate information about the internal structure of the AOS-CX host, leading to potential disclosure and limited modification of sensitive information.

🎖@cveNotify

🚨 CVE-2026-73758
A privilege escalation vulnerability exists in the API endpoint of AOS-CX. Successful exploitation could allow an authenticated low privilege operator user to change the state of certain settings of a vulnerable system.

🎖@cveNotify

🚨 CVE-2026-73759
Vulnerabilities in AOS-CX could allow an unauthenticated remote malicious actor to trigger a denial-of-service condition by sending specially crafted packets. Successful exploitation of these vulnerabilities results in disruption of normal operation on affected devices.

🎖@cveNotify

🚨 CVE-2026-73760
An authenticated Path Traversal vulnerability exists in AOS-CX. Successful exploitation of this vulnerability allows an attacker to read arbitrary files from the web-based management interface of the underlying operating system, which could lead to remote unauthorized access to files.

🎖@cveNotify

🚨 CVE-2026-73761
An out-of-bounds read vulnerability exists in the underlying operating system of AOS-CX that could lead to unauthenticated information disclosure by sending a specially crafted packet. Successful exploitation of this vulnerability results in the ability to disclose sensitive information from the underlying operating system.

🎖@cveNotify

🚨 CVE-2026-73762
A vulnerability has been identified in the API endpoint of AOS-CX that could allow a remote actor to circumvent existing access controls. In some cases this could enable unauthorized access to management functionality that should be restricted by the configured access control policy.

🎖@cveNotify

🚨 CVE-2026-73764
Vulnerabilities have been identified in the operating system of AOS-CX switches that could potentially allow an unauthenticated remote actor to circumvent existing authentication controls. In some cases this could enable unauthorized modification of affected resources and limited disruption of affected services.

🎖@cveNotify

🚨 CVE-2026-73765
Authenticated path traversal vulnerabilities exist in API endpoints of AOS-CX. Successful exploitation of these vulnerabilities allows an attacker to write arbitrary files to the underlying operating system, which could lead to remote code execution.

🎖@cveNotify

🚨 CVE-2026-73766
Command injection vulnerabilities in the API endpoint of AOS-CX could allow an authenticated remote attacker with administrative privileges to inject arbitrary commands. Successful exploitation could allow an attacker to execute arbitrary commands as a privileged user on the underlying operating system.

🎖@cveNotify

🚨 CVE-2026-73767
Authenticated command injection vulnerabilities exist in the command line interface of AOS-CX. Successful exploitation of these vulnerabilities results in the ability to execute arbitrary commands as a privileged user on the underlying operating system.

🎖@cveNotify