A vulnerability in the Linux kernel's vduse component caused incorrect handling of compat ioctl results, leading to file descriptor leaks. The issue arises because the compat handler processes certain ioctl commands but then calls the native handler, which returns an error that overwrites the intended return value, resulting in leaking one file descriptor per call. This has been resolved by returning handled compat results directly and only using native dispatch for other commands.
A vulnerability in the Linux kernel's vduse component allows invalid virtqueue alignment values to reach critical functions, potentially causing null pointer dereferences and kernel crashes. The issue arises because vduse_validate_config() only checks the upper bound of the alignment value, permitting zero or non-power-of-two values that violate the VIRTIO specification. This can lead to kernel memory corruption and system instability when opening virtio-net devices with improper alignment.
A vulnerability in the Linux kernel's vdpa_sim_net component was resolved. The issue involved improper handling of the TX pull result before using it in the RX copy path, where a negative error value was incorrectly treated as a large unsigned length. This could lead to incorrect memory operations. The vulnerability has a CVSS score of 7.5 and affects specific versions of the linux-hwe-edge kernel.
A vulnerability in the Linux kernel's vhost-vdpa component was resolved that involved improper handling of the eventfd_ctx_fdget() return value in the vhost_vdpa_set_config_call() function. The function swapped the return value into a configuration context field before checking for errors, briefly allowing an error pointer (ERR_PTR) to be stored. This could cause a rejected file descriptor to disrupt configuration interrupts, silently stopping them until a new file descriptor was installed by userspace.
A vulnerability in the Linux kernel's net/sched subsystem related to the Deficit Round Robin (DRR) queuing discipline was resolved. The issue involves improper handling of the quantum parameter in the drr_change_class() function, where an explicit quantum value of zero is rejected but a fallback to psched_mtu() occurs without a minimum floor. This can cause the deficit-refill loop to spin indefinitely under the qdisc lock when a crafted size table causes qdisc_pkt_len to reach approximately 2 GiB. The vulnerability requires the CONFIG_NET_SCH_DRR kernel configuration and CAP_NET_ADMIN privileges to exploit.
A vulnerability in the Linux kernel's net/sched subsystem (hhf qdisc) allows a crafted quantum value from userspace to cause a denial of service via a soft lockup. The hhf_change() function accepted any quantum, including 1, which could cause the deficit-refill loop to spin excessively under the qdisc lock. This issue requires CAP_NET_ADMIN privileges and specific configuration. The vulnerability has been resolved by clamping the quantum value in hhf_change() and hhf_init() to safe ranges.
A vulnerability in the Linux kernel's net/sched subsystem (sfq qdisc) allows a crafted quantum value to cause a denial of service by triggering a soft lockup. The issue arises because the sfq_change() function accepts any non-negative quantum, enabling a crafted packet length to cause the deficit-refill loop to spin excessively under the qdisc lock. This requires CAP_NET_ADMIN privileges and specific configuration to exploit.
A vulnerability in the Linux kernel's fq_pie network scheduler allows users with CAP_NET_ADMIN capability to cause a denial of service via a crafted quantum value. Specifically, the fq_pie_change() function accepts any quantum value from userspace, including 1, which can cause a soft lockup due to a long spinning loop under the qdisc lock. This issue affects certain versions of the linux-hwe-edge kernel and requires specific configuration and commands to trigger.
A vulnerability in the Linux kernel's network subsystem allowed unprivileged users in a user and network namespace to set an excessively large tx_queue_len value, leading to oversized ring buffer allocations and potential exhaustion of global memory. This was due to missing upper bounds on tx_queue_len in several subsystems such as pfifo_fast, tun, and tap. The issue was fixed by capping tx_queue_len at S16_MAX (32767) to reject oversized values at set time, preventing memory exhaustion.
A vulnerability in the Linux kernel's BPF subsystem allows a scalar store into an untrusted kernel pointer (kptr) field under certain conditions due to imprecise verifier checks. This flaw permits an attacker to write controlled bits into the kptr field and subsequently load them as a PTR_TO_BTF_ID. The issue arises because the verifier does not mark registers containing zero as precise, enabling a path with a nonzero value to be incorrectly accepted. The fix involves marking chain precision before accepting a known-zero register to ensure proper verification and rejection of invalid paths.
A vulnerability in the Linux kernel's persistent ring buffer validation was resolved by adding a check to ensure the saved number of sub-buffers (nr_subbufs) matches the expected value. The issue involved the code using meta->nr_subbufs without verifying it matched nr_pages + 1, potentially causing validation inconsistencies.
In the Linux kernel, the following vulnerability has been resolved: net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks() rds_tcp_reset_callbacks() quiesces the transmit path by setting the path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to be sampled clear before swapping the underlying socket and calling rds_send_path_reset(). Sampling the bit clear is not the same as owning it: rds_send_xmit() can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its state recheck after taking the lock is a store-buffering pattern (the resetter writes the state and reads the bit, the sender writes the bit and reads the state) and acquire_in_xmit() is only an acquire operation, so on weakly ordered architectures both sides can miss each other's write and the transmit path then runs concurrently with rds_send_path_reset() rewriting cp_xmit_* state - which is exactly what the comment above rds_send_path_reset() tells its callers to prevent. Take the lock instead, hold it across the socket swap and rds_send_path_reset(), and release it with a wake-up at the end. The lock-ordering constraint documented above the wait still holds: the lock is acquired before lock_sock(), so a sender inside tcp_sendmsg() can never be waited on while we hold the socket lock. Two details of the old code go away with the same change: - t_sock is now read only after the lock is acquired. The old code cached it before waiting; the teardown in rds_conn_shutdown() releases that socket and clears t_sock, so a pointer cached before the wait can be stale by the time the accept path resumes. Reading it under RDS_IN_XMIT is what makes the exclusion complete once the teardown owns the same lock, which the next patch arranges; until then the teardown still only samples the bit, and the two paths remain as exposed to each other as they are today. - The old !osock early path called rds_send_path_reset() with no serialization at all. It now runs under the lock like the normal path. The conditional RDS_CONN_RESETTING transition of the previous patch happens before the socket check either way: a path found without a socket is either still connecting (its reconnect worker blocked on t_conn_path_lock) and legitimately goes RESETTING -> UP on the new socket, or it has been torn down meanwhile and is dropped. The in-function comment describing the old wait-based quiesce is rewritten to describe the lock-based one, and the stale block comment above the function (which still described a return value and an incomplete list of t_sock writers) is refreshed to name all four writers - the connect, accept, teardown and swap paths - and what serializes each of them.
A vulnerability in the Linux kernel's Bluetooth L2CAP implementation allows an out-of-bounds write in the l2cap_ecred_connect function. This occurs because the function l2cap_chan_connect() incorrectly counts only deferred channels when limiting the number of pending ECRED channels, potentially causing one __le16 value to be written outside the bounds of the scid array and sending an invalid ECRED_CONN_REQ. The issue has been fixed by adjusting the counting logic to include non-deferred pending ECRED channels and moving the counting under a critical section to prevent exceeding the limit.
A vulnerability in the Linux kernel's Bluetooth component (btintel) was resolved. The issue involves improper handling of the firmware ID, which is treated as a NUL-terminated string despite only having a TLV length boundary. This can cause snprintf() to read beyond the intended buffer if the firmware ID lacks a NUL terminator. The fix limits the conversion to the advertised TLV value length.
A vulnerability in the Linux kernel's Bluetooth component (btintel) was resolved that involved improper validation of version TLV value lengths. The function btintel_parse_version_tlv() did not ensure that the value length was sufficient for the specific TLV type, which could lead to out-of-bounds reads. This issue was addressed by rejecting values shorter than the minimum required length and responses missing the Command Complete Status field.
A vulnerability in the Linux kernel's NTFS driver caused failed zeroing operations during file allocation to be silently ignored, potentially leaving stale data on disk. The issue was due to improper error handling in ntfs_dio_zero_range(), which never returns a positive value, but the zeroing failure check did not treat any nonzero return as an error. This flaw was fixed by treating any nonzero return as an error and aborting the allocation.
A vulnerability in the Linux kernel's EDAC device_sysfs interface involves improper handling of the poll_msec parameter. The original code used simple_strtoul() to parse this value, which accepts an unsigned long, but the poll_msec field is an unsigned int. On 64-bit systems, values larger than UINT_MAX are silently truncated, potentially causing unintended behavior. The issue is fixed by switching to kstrtouint(), which rejects values exceeding UINT_MAX and also rejects zero values to prevent CPU spinning.
A vulnerability in the Linux kernel's accel/amdxdna component involved the use of __counted_by annotation on a flexible array within the amdxdna_cmd_chain structure. This annotation relied on a userspace-controlled command_count value, which could be concurrently modified, potentially causing a kernel panic due to a failed bounds check. The issue has been resolved by removing the __counted_by annotation to prevent reliance on the mutable command_count for bounds checking.
A NULL pointer dereference vulnerability in the Linux kernel's mpi3mr driver was fixed. The issue occurs because sas_port_alloc_num() can return NULL on memory allocation failure, but this return value was not checked before being passed to sas_port_add(), leading to a potential NULL pointer dereference. Additionally, failure to free allocated memory on sas_port_add() failure could cause a memory leak. This vulnerability affects Linux kernel version 6.1.