| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor()
The v4l2 helper v4l2_async_register_subdev_sensor() calls
v4l2_async_register_subdev(), which is a macro that expands to
__v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded
inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module
rather than the sensor driver module that originally set sd->owner. When
v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then
overwrites the sensor driver's owner with NULL.
This causes the problem that the sensor module's reference count is never
incremented during async registration, so the module can be removed while
the subdevice is still in use by a notifier (e.g., a CSI-2 receiver
bridge driver).
Fix this by renaming v4l2_async_register_subdev_sensor() to
__v4l2_async_register_subdev_sensor() with an added explicit module
argument and introducing a wrapper macro:
#define v4l2_async_register_subdev_sensor(sd) \
__v4l2_async_register_subdev_sensor(sd, THIS_MODULE)
This ensures the sensor driver module is properly referenced even when
the sensor driver does not init the owner field before calling
v4l2_async_register_subdev_sensor() and prevents premature module removal. |
| In the Linux kernel, the following vulnerability has been resolved:
media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe
Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call
v4l2_subdev_init_finalize() which allocates the subdev active state,
but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup()
calls v4l2_subdev_cleanup() to free it.
This causes a memory leak on every rmmod, reported by kmemleak:
unreferenced object 0xffff0000d06fc800 (size 192):
comm "(udev-worker)", pid 254, jiffies 4294913455
backtrace (crc 36eeae58):
kmemleak_alloc+0x34/0x40
__kvmalloc_node_noprof+0x5f8/0x7d8
__v4l2_subdev_state_alloc+0x1fc/0x30c
__v4l2_subdev_init_finalize+0x178/0x368
Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup()
in both crossbar and pipe cleanup paths. |
| In the Linux kernel, the following vulnerability has been resolved:
media: msi2500: Return queued buffers on start_streaming() failure
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming(). If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.
msi2500_start_streaming() had five error paths that all hit this trap
and were further tangled by ret-overwriting between calls:
- -ENODEV when the USB device was already disconnected
- -ERESTARTSYS when mutex_lock_interruptible() was interrupted
- msi2500_set_usb_adc() failure: ret was silently overwritten by
the next call (msi2500_isoc_init), so the error was lost entirely
- msi2500_isoc_init() failure: cleanup_queued_bufs was called, but
the function then fell through to msi2500_ctrl_msg() and again
masked the original error by overwriting ret
- msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all,
leaving isoc URBs submitted with no way for the driver to consume
them
Consolidate the error paths into a small goto chain. Every failure
now stops the function, drains the queued-buffer list, and returns
the real error code. The ctrl_msg failure path also rolls back the
preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before
unlocking and draining.
The cleanup helper takes a vb2_buffer_state argument so that the
start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as
expected by userspace on start_streaming failure) while stop_streaming
keeps its existing VB2_BUF_STATE_ERROR semantics.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure"). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict
If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM
reference acquired earlier is not released, resulting in a reference
leak.
Fix this by dropping the MM reference on the kvmalloc_array()
failure path. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: hvs/v3d: Fix null dereference in unbind
The hvs and v3d drivers use dev_get_drvdata(master) in their unbind
functions. Since the vc4-drm gets removed before its dependent drivers
(vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to
get drvdata of its master and fails with a null dereference error.
Use the data pointer passed to the unbind functions directly instead of
dev_get_drvdata(master). This avoids using potentially freed memory. |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid
sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the
capacity limit for ep->auth_chunk_list, allowing it to hold up to
20 chunk entries (param_hdr.length up to 24). However, the copy
destination asoc->c.auth_chunks in struct sctp_cookie is only
SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16
chunks are added, sctp_association_init() memcpy overflows the
destination by up to 4 bytes.
Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching
the destination capacity. |
| Lack of authentication for Very High Frequency Data Link messages allows rogue ground stations to inject CPDLC messages leading to unexpected or misleading clearances and potential pilot confusion. This type of attack can be carried out remotely over radio frequency. |
| Consul Community Edition and Consul Enterprise 1.19.1 through 2.0.2 did not enforce the {{session:write}} ACL permission for session deletion operations submitted through the transaction API. An authenticated caller with network access to the Consul server RPC port could delete arbitrary sessions without holding the required permission. This vulnerability, CVE-2026-19016, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3. |
| Consul Community Edition and Consul Enterprise 1.18.0 through 2.0.2 are vulnerable to an authenticated denial of service in the Enterprise-to-Community Edition downgrade path that may allow an authorized caller to crash the Consul server. A caller with config-entry write permission can submit a service-router configuration entry that causes the agent to exit unexpectedly. This vulnerability, CVE-2026-19012, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3. |
| Consul Community Edition and Consul Enterprise 1.17.0 through 2.0.2 are vulnerable to an uncontrolled resource consumption issue in the Connect authorization endpoint that may allow a caller to grow the agent's intention-match cache without bound, defeating the operator's cache-disable configuration. This vulnerability, CVE-2026-190124, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3. |
| Consul Community Edition and Consul Enterprise 1.2.0 through 2.0.2 are vulnerable to an uncontrolled resource consumption issue in the Connect CA roots endpoint that may allow a remote caller to grow the agent's Connect CA roots cache without bound, defeating the operator's cache-disable configuration. This vulnerability, CVE-2026-19015, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3. |
| Consul Community Edition and Consul Enterprise 1.20.1 through 2.0.2 are vulnerable to an L7 intention authorization bypass when a service proxy is configured with a custom public listener. An authenticated mesh workload may reach HTTP paths that are blocked by a path-based deny intention. This vulnerability, CVE-2026-15970, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3. |
| Consul Community Edition and Consul Enterprise 1.13.0 through 2.0.2 are vulnerable to an unauthenticated denial of service through unbounded connection acceptance on the external gRPC listeners. A remote attacker may exhaust agent file descriptors, goroutines, and memory by opening many incomplete connections, potentially preventing legitimate clients from connecting. This vulnerability, CVE-2026-15972, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3. |
| Consul Community Edition and Consul Enterprise 1.3.0 through 2.0.2 are vulnerable to an unauthenticated denial of service in several agent HTTP API endpoints. A remote caller could cause the agent to consume substantial memory before the request was rejected. This vulnerability, CVE-2026-19113, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3. |
| A denial-of-service
vulnerability exists in httpd service on Archer A6 v4 where the asynchronous systool
instruction handlng path in httpd does not properly synchronize or safely manage
concurrent systool operations.
By sending
crafted systool instructions through the asynchronous request path, successful
exploitation may cause the httpd process or device management service to crash
and may result in temporary loss of access to the web management interface or
device reboot. |
| An input validation
vulnerability exists in the HTTP-WRITEOEM handler due to insufficient validation
of user-supplied data before it is processed by internal flash-write handling
logic.
Successful
exploitation may cause httpd process or device to crash, resulting in loss of access
to the web interface and a denial-of-service condition. |
| The kernel queue helper z_queue_node_peek() in kernel/queue.c dereferences a node taken from a queue's data_q list, reading the node's flag byte and, for items enqueued via k_queue_alloc_append/alloc_prepend, the data pointer of an internally allocated alloc_node struct. The implementations of z_impl_k_queue_peek_head() and z_impl_k_queue_peek_tail() performed this read-and-dereference without holding the queue's spinlock, while every other accessor of the same list — including k_queue_get(), which unlinks a node and k_free()s its backing alloc_node — operates under that lock.
Because peek was unsynchronized, a concurrent k_queue_get() on the same queue (on an SMP build, or under preemption/ISR concurrency) can free the node between the moment peek obtains the node pointer and the moment it dereferences it. The peek then reads flag bits and a data pointer out of freed, potentially re-allocated heap memory and returns a stale or dangling pointer to its caller. k_fifo and k_lifo are thin wrappers over k_queue, so this affects buffer queues used throughout the net_buf, Bluetooth, USB, and networking subsystems; the peek operations are also system calls reachable from CONFIG_USERSPACE threads.
The consequences are a use-after-free read that can leak stale heap contents (one pointer word) and, when the returned dangling pointer is subsequently consumed as a live buffer, a dereference that can crash the system or corrupt memory. Exploitation requires winning a small race window with local access (e.g. a userspace process racing k_queue_peek_* against k_queue_get on a shared queue, or two CPUs), so practical impact is bounded and of low severity.
The fix wraps both peek implementations with k_spin_lock/k_spin_unlock on the queue lock, making the read-and-dereference atomic with respect to the concurrent unlink-and-free and bringing peek into line with the rest of the queue's locking discipline. |
