| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
soc: ti: k3-socinfo: Fix regmap leak on probe failure
The mmio regmap allocated during probe is never freed.
Switch to using the device managed allocator so that the regmap is
released on probe failures (e.g. probe deferral) and on driver unbind. |
| In the Linux kernel, the following vulnerability has been resolved:
writeback: Fix use after free in inode_switch_wbs_work_fn()
inode_switch_wbs_work_fn() has a loop like:
wb_get(new_wb);
while (1) {
list = llist_del_all(&new_wb->switch_wbs_ctxs);
/* Nothing to do? */
if (!list)
break;
... process the items ...
}
Now adding of items to the list looks like:
wb_queue_isw()
if (llist_add(&isw->list, &wb->switch_wbs_ctxs))
queue_work(isw_wq, &wb->switch_work);
Because inode_switch_wbs_work_fn() loops when processing isw items, it
can happen that wb->switch_work is pending while wb->switch_wbs_ctxs is
empty. This is a problem because in that case wb can get freed (no isw
items -> no wb reference) while the work is still pending causing
use-after-free issues.
We cannot just fix this by cancelling work when freeing wb because that
could still trigger problematic 0 -> 1 transitions on wb refcount due to
wb_get() in inode_switch_wbs_work_fn(). It could be all handled with
more careful code but that seems unnecessarily complex so let's avoid
that until it is proven that the looping actually brings practical
benefit. Just remove the loop from inode_switch_wbs_work_fn() instead.
That way when wb_queue_isw() queues work, we are guaranteed we have
added the first item to wb->switch_wbs_ctxs and nobody is going to
remove it (and drop the wb reference it holds) until the queued work
runs. |
| In the Linux kernel, the following vulnerability has been resolved:
driver core: enforce device_lock for driver_match_device()
Currently, driver_match_device() is called from three sites. One site
(__device_attach_driver) holds device_lock(dev), but the other two
(bind_store and __driver_attach) do not. This inconsistency means that
bus match() callbacks are not guaranteed to be called with the lock
held.
Fix this by introducing driver_match_device_locked(), which guarantees
holding the device lock using a scoped guard. Replace the unlocked calls
in bind_store() and __driver_attach() with this new helper. Also add a
lock assertion to driver_match_device() to enforce this guarantee.
This consistency also fixes a known race condition. The driver_override
implementation relies on the device_lock, so the missing lock led to the
use-after-free (UAF) reported in Bugzilla for buses using this field.
Stress testing the two newly locked paths for 24 hours with
CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled showed no UAF recurrence
and no lockdep warnings. |
| In the Linux kernel, the following vulnerability has been resolved:
EDAC/mc: Fix error path ordering in edac_mc_alloc()
When the mci->pvt_info allocation in edac_mc_alloc() fails, the error path
will call put_device() which will end up calling the device's release
function.
However, the init ordering is wrong such that device_initialize() happens
*after* the failed allocation and thus the device itself and the release
function pointer are not initialized yet when they're called:
MCE: In-kernel MCE decoding enabled.
------------[ cut here ]------------
kobject: '(null)': is not initialized, yet kobject_put() is being called.
WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd
CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)
RIP: 0010:kobject_put
Call Trace:
<TASK>
edac_mc_alloc+0xbe/0xe0 [edac_core]
amd64_edac_init+0x7a4/0xff0 [amd64_edac]
? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]
do_one_initcall
...
Reorder the calling sequence so that the device is initialized and thus the
release function pointer is properly set before it can be used.
This was found by Claude while reviewing another EDAC patch. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: thead: Fix buffer overflow and use standard endian macros
Addresses two issues in the TH1520 AON firmware protocol driver:
1. Fix a potential buffer overflow where the code used unsafe pointer
arithmetic to access the 'mode' field through the 'resource' pointer
with an offset. This was flagged by Smatch static checker as:
"buffer overflow 'data' 2 <= 3"
2. Replace custom RPC_SET_BE* and RPC_GET_BE* macros with standard
kernel endianness conversion macros (cpu_to_be16, etc.) for better
portability and maintainability.
The functionality was re-tested with the GPU power-up sequence,
confirming the GPU powers up correctly and the driver probes
successfully.
[ 12.702370] powervr ffef400000.gpu: [drm] loaded firmware
powervr/rogue_36.52.104.182_v1.fw
[ 12.711043] powervr ffef400000.gpu: [drm] FW version v1.0 (build
6645434 OS)
[ 12.719787] [drm] Initialized powervr 1.0.0 for ffef400000.gpu on
minor 0 |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix locking usage for tcon fields
We used to use the cifs_tcp_ses_lock to protect a lot of objects
that are not just the server, ses or tcon lists. We later introduced
srv_lock, ses_lock and tc_lock to protect fields within the
corresponding structs. This was done to provide a more granular
protection and avoid unnecessary serialization.
There were still a couple of uses of cifs_tcp_ses_lock to provide
tcon fields. In this patch, I've replaced them with tc_lock. |
| In the Linux kernel, the following vulnerability has been resolved:
media: verisilicon: AV1: Fix tile info buffer size
Each tile info is composed of: row_sb, col_sb, start_pos
and end_pos (4 bytes each). So the total required memory
is AV1_MAX_TILES * 16 bytes.
Use the correct #define to allocate the buffer and avoid
writing tile info in non-allocated memory. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add signal type check for dcn401 get_phyd32clk_src
Trying to access link enc on a dpia link will cause a crash otherwise |
| Memory corruption when dynamically changing the size of a previously allocated buffer while its contents are being modified. |
| Memory corruption when processing camera sensor input/output control codes with invalid output buffers. |
| Memory corruption when another driver calls an IOCTL with invalid input/output buffer. |
| Information Disclosure while processing IOCTL handler callbacks without verifying buffer size. |
| A vulnerability in an identity management API endpoint of Cisco ISE could allow an unauthenticated, remote attacker to enumerate valid user accounts on an affected device.
This vulnerability exists because error messages are observed when the affected API endpoint is called. An attacker could exploit this vulnerability by sending a series of crafted requests to the affected endpoint and analyzing the differentiated responses. A successful exploit could allow the attacker to compile a list of valid usernames on an affected system. |
| A vulnerability in the web-based management interface of Cisco IoT Field Network Director could allow an authenticated, remote attacker with low privileges to retrieve files that they do not have permission to access.
This vulnerability is due to insufficient file access checks. An attacker could exploit this vulnerability by submitting crafted input in the web-based management interface. A successful exploit could allow the attacker to read files that they are not authorized to access. |
| An issue in D-Link DIR-1253 MESH V1.6.1684 allows an attacker to escalate privileges via the etc/shadow.sample component |
| OpenCode Systems OC Messaging / USSD Gateway OC Release 6.32.2 contains a broken access control vulnerability in the web-based control panel allowing authenticated low-privileged attackers to gain to access to arbitrary SMS messages via a crafted company or tenant identifier parameter. |
| Hitachi Vantara Pentaho Data Integration & Analytics versions before 10.2.0.6, including 9.3.x and 8.3.x, do not restrict Groovy scripts in new PRPT reports published by users, allowing insertion of arbitrary scripts and leading to a RCE. |
| A vulnerability in the RADIUS Policy API endpoints of Cisco ISE could allow an authenticated, remote attacker with read-only Administrator privileges to gain unauthorized access to sensitive information on an affected device.
This vulnerability is due to improper role-based access control (RBAC) permissions on the RADIUS Policy API endpoints. An attacker could exploit this vulnerability by bypassing the web-based management interface and directly calling an affected endpoint. A successful exploit could allow the attacker to gain unauthorized read access to sensitive RADIUS Policy details that are restricted for their role. |
| A vulnerability in the Simple Network Management Protocol (SNMP) subsystem of Cisco 350 Series Managed Switches (SG350) and Cisco 350X Series Stackable Managed Switches (SG350X) firmware could allow an authenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.
This vulnerability is due to improper error handling when parsing response data for a specific SNMP request. An attacker could exploit this vulnerability by sending a specific SNMP request to an affected device. A successful exploit could allow the attacker to cause the device to reload unexpectedly, resulting in a DoS condition.
This vulnerability affects SNMP versions 1, 2c, and 3. To exploit this vulnerability through SNMPv2c or earlier, the attacker must know a valid read-write or read-only SNMP community string for the affected system. To exploit this vulnerability through SNMPv3, the attacker must have valid SNMP user credentials for the affected system. |
| A vulnerability in the log file download functionality of Cisco Prime Infrastructure could allow an authenticated, remote attacker to download arbitrary log files from the server.
This vulnerability is due to insufficient authorization checks on the download service API. An attacker could exploit this vulnerability by submitting a crafted URL request to an affected device. A successful exploit could allow the attacker to download sensitive log files that they would otherwise not have authorization to access.
To exploit this vulnerability, the attacker must have valid credentials to access the web-based management interface of the affected device. |
