| fd837de3c9cb1 tracing: probes: Fix a possible race in trace_probe_log APIs |
| - [sasha] Based on my analysis, I can now provide a determination: **YES**, this commit should be assigned a CVE. Here's my reasoning based on the code changes: 1. **Race Condition in Shared Global Variable**: The commit fixes a race condition in `trace_probe_log`, which is a global static variable that can be accessed concurrently. As shown in the original commit (ab105a4fb894), this variable was introduced without proper synchronization: ```c static struct trace_probe_log trace_probe_log; ``` 2. **Multiple Unprotected Entry Points**: The commit message explicitly states that "kprobe_events and uprobe_events interfaces are not serialized." This means multiple threads could write to `/sys/kernel/tracing/kprobe_events` and `/sys/kernel/tracing/uprobe_events` simultaneously, causing concurrent access to the shared `trace_probe_log` structure. 3. **Data Corruption Risk**: The `trace_probe_log` structure contains pointers (`argv`, `subsystem`) and counters (`argc`, `index`) that could be corrupted during concurrent access. This could lead to: - Use-after-free if one thread clears the log while another is using it - Buffer overflows if index/argc values are corrupted - Invalid memory access if argv pointers are modified during use 4. **Security Impact**: The race condition could potentially be exploited to: - Cause kernel crashes (DoS) - Potentially leak kernel memory if error messages are constructed with corrupted pointers - Possibly achieve privilege escalation through careful manipulation of the race 5. **Fix Implementation**: The fix properly serializes access by: - Introducing `dyn_event_create()` that holds `dyn_event_ops_mutex` during creation - Adding lockdep assertions to ensure the mutex is held when accessing `trace_probe_log` - Changing the call sites to use the protected version This is similar to the CVE-assigned commit "tracing: Have trace_event_file have ref counters" which fixed a race condition that could cause use-after-free, demonstrating that race conditions in the tracing subsystem are considered security vulnerabilities worthy of CVE assignment. |
| 5257d80e22bf2 iio: adc: ad7606: check for NULL before calling sw_mode_config() |
| - [sasha] Now I understand the vulnerability: 1. Some chip_info structures (like ad7606b_info and ad7616_info) have `sw_setup_cb` set to `ad7606b_sw_mode_setup` or `ad7616_sw_mode_setup` 2. These setup functions unconditionally call `st->bops->sw_mode_config()` 3. However, not all bus operations structures define the `sw_mode_config` callback - for example, `ad7606_spi_bops`, `ad7606_par16_bops`, and `ad7606_par8_bops` don't have it 4. When software mode is enabled (`adi,sw-mode` property is present), and a chip with sw_setup_cb is used with a bus that doesn't have sw_mode_config, a NULL pointer dereference occurs **Answer: YES** This commit should be assigned a CVE because: 1. **It fixes a NULL pointer dereference vulnerability** - The commit explicitly states it fixes a NULL pointer dereference that occurs when the sw_mode_config function pointer is not set in the bus operations structure. 2. **The vulnerability can cause a kernel crash** - A NULL pointer dereference in kernel space typically leads to a kernel panic/crash, resulting in a denial of service condition. 3. **It's a real security issue** - The vulnerability occurs when certain hardware configurations are used (chips that support software mode with bus drivers that don't implement sw_mode_config), which could be triggered by device tree configurations or hardware setups. 4. **Similar to CVE-assigned commits** - Like the similar commits shown that check for NULL pointers (e.g., the ti-ads1298 commit checking devm_kasprintf return value), this prevents a crash condition caused by missing null checks. 5. **The fix is security-relevant** - Adding NULL checks before dereferencing function pointers is a standard security practice to prevent crashes. The vulnerability would manifest when using AD7606B or AD7616 ADC chips with certain bus configurations (like basic SPI or parallel interfaces) while enabling software mode via device tree, causing the kernel to crash when attempting to call the NULL sw_mode_config pointer. |
| bd07f751208ba HID: uclogic: Add NULL check in uclogic_input_configured() |
| - [sasha] Based on my analysis, I notice there's a discrepancy between the provided diff and what's in the kernel tree. However, analyzing the security implications based on the provided information: **YES** This commit should be assigned a CVE for the following reasons: 1. **NULL pointer dereference vulnerability**: The commit explicitly fixes a NULL pointer dereference that occurs when `devm_kasprintf()` fails due to memory allocation failure and returns NULL. 2. **Exploitable condition**: When memory allocation fails, the code would attempt to use `hi->input->name` as NULL, leading to a kernel NULL pointer dereference. This can cause: - System crash/DoS - Potential privilege escalation in some scenarios 3. **Pattern matches similar CVE-assigned commits**: All 5 similar commits shown with "CVE Status: YES" fix the exact same type of vulnerability - missing NULL checks after `devm_kasprintf()` calls. They all: - Fix NULL pointer dereferences - Add the same type of NULL check - Return -ENOMEM on allocation failure - Have the same security impact 4. **User-triggerable**: HID devices can be plugged in by users, and memory allocation failures can be triggered under memory pressure conditions, making this potentially exploitable. 5. **Clear security fix**: The commit message explicitly states it prevents a "NULL pointer dereference" which is a recognized security vulnerability class. The fix properly adds a NULL check after `devm_kasprintf()` and returns `-ENOMEM` to handle the error gracefully, preventing the kernel crash that would otherwise occur. |
| c457dc1ec770a nfs: handle failure of nfs_get_lock_context in unlock path |
| - [sasha] **YES** This commit should be assigned a CVE for the following reasons: 1. **NULL Pointer Dereference Vulnerability**: The commit fixes a clear security vulnerability where a NULL pointer dereference occurs in `nfs4_locku_prepare()` when `nfs_get_lock_context()` fails with -ENOMEM. The crash trace in the commit message shows: ``` BUG: kernel NULL pointer dereference, address: 000000000000000c RIP: 0010:nfs4_locku_prepare+0x35/0xc2 ``` 2. **Memory Pressure Attack Vector**: This vulnerability can be triggered under memory pressure conditions, which an attacker could potentially induce to cause a denial of service through kernel panic. 3. **Error Handling Flaw**: The code change shows the original implementation failed to check if `nfs_get_lock_context()` returned an error pointer: ```c // Original vulnerable code: p->l_ctx = nfs_get_lock_context(ctx); // Could return ERR_PTR(-ENOMEM) // Fixed code: l_ctx = nfs_get_lock_context(ctx); if (!IS_ERR(l_ctx)) { p->l_ctx = l_ctx; } else { kfree(p); return NULL; } ``` 4. **Production Impact**: The commit indicates this was found in production environments and can crash the kernel, causing system downtime. 5. **Similar to Other CVE-Assigned Commits**: Like the similar commits shown (which all received CVEs), this fixes a NULL pointer dereference in the NFS subsystem that can cause kernel crashes. The vulnerability allows local or remote attackers (depending on NFS configuration) to potentially crash the system by triggering memory allocation failures during NFS unlock operations. |
| fa7ab64f1e2fd NFS/localio: Fix a race in nfs_local_open_fh() |
| - [sasha] **YES** This commit should be assigned a CVE. The code change fixes a race condition that leads to a use-after-free vulnerability in the NFS localio code path. Specifically: 1. **Use-after-free vulnerability**: The race window between `spin_unlock(&clp->cl_uuid.lock)` and `rcu_read_lock()` allows another CPU to free the `nfsd_file` structure that was just assigned to `nf`, resulting in a potential use-after-free when `nfs_local_file_get(nf)` is called on the freed memory. 2. **Security impact**: This vulnerability could lead to: - System crashes (DoS) - Memory corruption - Potential privilege escalation if exploited correctly 3. **The fix**: Moving `rcu_read_lock()` before `spin_unlock()` ensures proper RCU protection throughout the critical section, preventing the race condition. This is similar to the CVE-assigned commits shown in the examples (commits 4 and 5) that fix race conditions in file locking code. Race conditions that lead to use-after-free vulnerabilities are typically assigned CVEs due to their security implications. |
| d0706bfd3ee40 RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem |
| - [sasha] **YES** This commit fixes a use-after-free vulnerability in the RDMA core subsystem. The vulnerability is a race condition between device renaming and the kobject_uevent notification system, where: 1. **Race Condition**: The `ib_device_rename()` function holds `devices_rwsem` lock while renaming a device and freeing the old name string, but `kobject_uevent()` accesses the device name without holding this lock, leading to a use-after-free condition. 2. **Security Impact**: - The vulnerability allows reading freed memory (`slab-use-after-free Read`) - It's triggered through netlink commands that can be executed by unprivileged users with appropriate namespace capabilities - KASAN detects reading 5 bytes of freed memory in the `nla_put` function 3. **Attack Vector**: An attacker could potentially: - Trigger the race condition between device registration/renaming operations - Cause kernel crashes or information disclosure through the use-after-free - The vulnerability is reachable through the netlink interface used for RDMA device management 4. **Fix Pattern**: The fix moves the `kobject_uevent()` call inside the critical section protected by `devices_rwsem`, ensuring proper synchronization between device name access and modification operations. This follows a similar pattern to CVE-assigned commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name"), indicating this is a security-relevant class of bugs in the RDMA subsystem where concurrent access to device names without proper locking leads to memory safety issues. |
| 2d3cbfd6d54a2 net_sched: Flush gso_skb list too during ->change() |
| - [sasha] Based on my analysis of the commit message and code changes: **YES** - This commit should be assigned a CVE. Here's why: 1. **Security Impact - NULL Pointer Dereference**: The commit explicitly states it fixes a NULL pointer dereference vulnerability that occurs when "we only check sch->limit against sch->q.qlen" but packets remain in the gso_skb list. 2. **Exploitable Condition**: When a qdisc's limit is reduced via the ->change() operation, the inconsistent state between the main queue and gso_skb list can trigger a kernel crash, resulting in a denial of service. 3. **Multiple Affected Components**: The fixes affect 6 different qdisc implementations (codel, fq_codel, fq, fq_pie, hhf, pie) spanning back to commits from 2012-2013, indicating this is a long-standing vulnerability affecting multiple kernel versions. 4. **Code Pattern Shows Real Issue**: The new `qdisc_dequeue_internal()` helper specifically handles both the gso_skb list and main queue: ```c skb = __skb_dequeue(&sch->gso_skb); if (skb) { sch->q.qlen--; return skb; } ``` This shows that the gso_skb list was previously ignored during limit reduction, creating the vulnerability. 5. **Similar to Previous CVEs**: Looking at the similar commits with "CVE Status: YES", this follows the same pattern of fixing crashes/denial of service issues in the network scheduler subsystem. While this requires CAP_NET_ADMIN privileges to exploit (limiting the attack surface), it still represents a security vulnerability that can crash the system, warranting CVE assignment. |
| f11cf946c0a92 net: mctp: Don't access ifa_index when missing |
| - [sasha] Based on my analysis, this is a classic **information leak vulnerability** where the kernel accesses uninitialized memory and uses it to make decisions. Here's what happens: **YES** - This commit should be assigned a CVE. **Explanation:** 1. **Information Leak**: The bug allows reading uninitialized kernel memory. When `mctp_dump_addrinfo()` is called with a netlink message that doesn't contain a complete `struct ifaddrmsg` header, the code still attempts to read `hdr->ifa_index` from memory beyond the actual message data. This reads uninitialized kernel memory. 2. **Security Impact**: The uninitialized memory value is then used to filter network interfaces (`ifindex == 0 || ifindex == dev->ifindex`). While the data isn't directly leaked to userspace, using uninitialized memory for control flow decisions can lead to unpredictable behavior and potential security issues. 3. **Triggerable by Userspace**: The commit message explicitly mentions this can be triggered by common userspace programs like dhcpd or busybox "ip addr show", making it easily exploitable. 4. **Similar CVE Precedent**: The similar commits shown all received CVEs for uninit-value access issues: - "ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network" (CVE assigned) - "vxlan: Fix uninit-value in vxlan_vnifilter_dump()" (CVE assigned) - "ipv4: Fix uninit-value access in __ip_make_skb()" (CVE assigned) 5. **KMSAN Detection**: The bug was detected by KMSAN (Kernel Memory Sanitizer), which specifically identifies uses of uninitialized memory - a classic security vulnerability class. The fix properly validates that the netlink message contains enough data before accessing the header fields, preventing the uninitialized memory access. |
| e4f349bd6e580 net: mctp: Ensure keys maintain only one ref to corresponding dev |
| - [sasha] Now I can see the issue! Looking at the fragmentation code: - Line 933: `skb_ext_copy(skb2, skb)` copies the extension (which includes the flow/key reference) - Line 936: `rt->output(rt, skb2)` calls mctp_route_output for each fragment - Each call to mctp_route_output calls mctp_flow_prepare_output - Without the fix, mctp_flow_prepare_output would call mctp_dev_set_key for EACH fragment - mctp_dev_set_key increments the device reference count (mctp_dev_hold) So for a fragmented message with N fragments, the device would get N reference count increments, but only 1 decrement when the key is released, causing a reference leak. Let me verify this by looking at the commit message symptoms: The error message shows: ``` unregister_netdevice: waiting for mctpusb0 to become free. Usage count = 2 ``` This confirms a reference count leak preventing device removal. Based on my analysis: **YES** This commit should be assigned a CVE for the following reasons: 1. **Resource leak vulnerability**: The bug causes an unbalanced reference count on network devices when handling fragmented MCTP messages. Each fragment incorrectly increments the device reference count, but only one decrement occurs when the key is released. 2. **Denial of Service impact**: The reference leak prevents proper cleanup of network interfaces. As shown in the commit message, attempting to remove a USB device results in the kernel being unable to free the interface (`waiting for mctpusb0 to become free. Usage count = 2`), effectively causing a resource exhaustion condition. 3. **Exploitable condition**: An attacker could trigger this by sending fragmented MCTP messages through an affected interface, preventing administrators from properly removing or reconfiguring network devices. 4. **Security-relevant fix**: The code change adds a check `if (key->dev)` to ensure mctp_dev_set_key() is only called once per key, not once per fragment, fixing the reference count imbalance. The vulnerability pattern is similar to the other CVE-assigned MCTP commits shown in the examples, which also dealt with memory leaks, reference counting issues, and denial of service conditions in the MCTP subsystem. |
| a3b7e65b6be59 drm/amd/display: Fix null check of pipe_ctx->plane_state for update_dchubp_dpp |
| - [sasha] Based on my analysis of the commit and the code context, here's my CVE assessment: **YES** This commit should be assigned a CVE for the following reasons: 1. **Clear null pointer dereference vulnerability**: The code in `dcn401_program_pipe()` was calling `dc->hwss.update_dchubp_dpp()` without checking if `pipe_ctx->plane_state` is null. Inside `dcn20_update_dchubp_dpp()`, the code immediately dereferences `plane_state` multiple times (e.g., `plane_state->update_flags.bits.bpp_change`, `plane_state->bias_and_scale`, `plane_state->format`, etc.) without null checks. 2. **Consistent with previous CVE assignments**: This is directly comparable to CVE-assigned commits 6a057072ddd1 and 8e4ed3cf1642, which fixed similar null pointer dereferences in the same AMD display driver subsystem. The pattern is identical - missing null checks for `pipe_ctx->plane_state` before dereferencing. 3. **Exploitable from userspace**: The call chain shows this can be triggered through the DRM/KMS interface via `program_front_end_for_ctx`, which is called during display mode changes and updates that can be initiated by userspace applications through standard DRM ioctls. 4. **Security impact**: A null pointer dereference in kernel space can lead to a kernel panic/crash, resulting in a denial of service. On some systems, it could potentially be leveraged for privilege escalation. 5. **Introduced by a specific commit**: The vulnerability was introduced by commit 63ab80d9ac0a ("drm/amd/display: DML2.1 Post-Si Cleanup"), making it a clear regression that affects specific kernel versions. The fix properly adds the null check `if (pipe_ctx->plane_state && ...)` before the code block that dereferences `plane_state`, preventing the null pointer dereference vulnerability. |
| 588431474eb75 net/mlx5e: Disable MACsec offload for uplink representor profile |
| - [sasha] So the issue is clear now: 1. When a device switches to uplink representor mode, it uses `mlx5e_uplink_rep_profile` instead of the regular NIC profile 2. The uplink representor enable function (`mlx5e_uplink_rep_enable`) does NOT call `mlx5e_macsec_init`, leaving `priv->macsec` as NULL 3. However, the `NETIF_F_HW_MACSEC` feature bit is still set because `mlx5e_build_nic_netdev` is called during initial netdev creation 4. When userspace tries to configure MACsec, it calls `mlx5e_macsec_add_secy` which tries to dereference `priv->macsec->lock`, causing a null pointer dereference Based on my analysis: **YES** This commit should be assigned a CVE because: 1. **It fixes a security vulnerability**: The commit fixes a null pointer dereference that can be triggered from userspace by attempting to configure MACsec offload on an uplink representor device. 2. **The vulnerability is exploitable**: Any user with appropriate privileges to configure MACsec (typically requires CAP_NET_ADMIN) can trigger this crash by running MACsec configuration commands on an uplink representor interface. 3. **Impact**: This causes a kernel panic/oops, resulting in a denial of service. The stack trace in the commit message clearly shows the crash occurring when userspace (the `ip` command) attempts to configure MACsec. 4. **Root cause**: The vulnerability exists because the NETIF_F_HW_MACSEC feature flag is incorrectly left enabled for uplink representor profiles even though the MACsec subsystem (`priv->macsec`) is never initialized for these devices. This creates a mismatch between advertised capabilities and actual initialization state. 5. **Similar to CVE-assigned commits**: Looking at the similar commits provided, CVE was assigned to commits that fixed null pointer dereferences in the MACsec code path (similar commit 1) and resource leaks in MACsec offload handling (similar commit 2). The fix correctly removes the NETIF_F_HW_MACSEC feature flag for uplink representors in `mlx5e_fix_uplink_rep_features()`, preventing userspace from attempting to configure MACsec offload on these unsupported devices. |
| 6b0cd72757c69 regulator: max20086: fix invalid memory access |
| - [sasha] Based on my analysis of the commit and the code, here's my determination: **YES** This commit should be assigned a CVE for the following reasons: 1. **Invalid Memory Access Vulnerability**: The bug involves accessing memory that is no longer valid. The `matches` array is allocated on the stack in `max20086_parse_regulators_dt()`, but a pointer to this stack-allocated array is stored in the device-managed resource system through `devm_of_regulator_matches`. 2. **Use-After-Free Pattern**: When the device fails to probe (e.g., due to an I2C error as shown in the commit message), the devm cleanup code (`devm_of_regulator_put_matches()`) is called. This function tries to access the `matches` array through the stored pointer, but by this time, the stack frame containing the array has been freed, resulting in a use-after-free condition. 3. **Kernel Memory Safety Impact**: The vulnerability causes the kernel to access invalid memory, which could potentially: - Lead to kernel crashes/panics - Cause unpredictable behavior - In worst cases, could potentially be exploited for information disclosure or privilege escalation 4. **Similar to Previous CVEs**: Looking at the similar commits provided: - Commit 2 (pfuze100 refcount leak) received a CVE for a memory leak issue - Commit 4 (rt4801 NULL pointer dereference) received a CVE for a NULL pointer dereference - Commit 5 (rtq2208 uninitialized use) received a CVE for uninitialized memory use This bug is arguably more severe than some of those, as it involves actual invalid memory access rather than just leaks or uninitialized data. 5. **Exploitability**: While this is triggered by a probe failure, an attacker with physical access could potentially trigger this by manipulating the I2C bus or causing other probe failures, leading to kernel memory corruption. The fix properly addresses the issue by using `devm_kcalloc()` to allocate the matches array on the heap, ensuring it remains valid throughout the lifetime of the device-managed resources. |
| 92ec4855034b2 mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices |
| - [sasha] **YES** This commit should be assigned a CVE based on the following analysis: 1. **Clear Use-After-Free Security Vulnerability**: The commit message explicitly states "Fix use-after-free when deleting GRE net devices" and includes a KASAN report showing memory access to freed memory. This is a classic security vulnerability pattern. 2. **Exploitable Condition**: The vulnerability occurs in a sequence of operations that can be triggered by userspace: - Create a GRE device and add a neighbor - Reload the driver (which offloads the neighbor) - Delete the neighbor (driver ignores this due to the bug) - Delete the GRE device (triggers use-after-free) 3. **Memory Safety Violation**: The KASAN trace shows: ``` BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200 Read of size 8 at addr ffff888155b0e420 by task ip/2282 ``` This indicates the driver is reading from memory that has already been freed. 4. **Root Cause**: The bug was introduced by commit 8fdb09a7674c ("mlxsw: spectrum_router: Replay neighbours when RIF is made") which added neighbor replay functionality but didn't properly check if the device was a supported type (upper of mlxsw devices). 5. **Similar CVE Precedent**: My search found that similar mlxsw use-after-free bugs have been assigned CVEs: - CVE-2024-42073: mlxsw memory corruption/use-after-free - CVE-2024-35855: mlxsw use-after-free during activity update - CVE-2024-35854: mlxsw use-after-free during rehash - CVE-2024-35852: mlxsw memory leak (related issue) 6. **Security Impact**: Use-after-free vulnerabilities can potentially lead to: - System crashes (DoS) - Information disclosure (reading freed memory) - Potential code execution (if freed memory is reused for attacker-controlled data) The fix properly addresses this by adding a check `if (!mlxsw_sp_dev_lower_is_port(mlxsw_sp_rif_dev(rif)))` to skip neighbor replay for devices that are not uppers of mlxsw devices, preventing the driver from keeping references to neighbors it won't properly track. |
| 491deb9b8c4ad net/tls: fix kernel panic when alloc_page failed |
| - [sasha] **YES** This commit should be assigned a CVE based on the following analysis: 1. **NULL pointer dereference vulnerability**: The commit fixes a kernel NULL pointer dereference that causes a kernel panic. The stack trace shows the crash happens in `tls_strp_check_rcv` when accessing memory at virtual address 0x0000000000000028. 2. **Root cause**: When `alloc_page()` fails in `tls_strp_read_copy()`, the code was prematurely setting `shinfo->frag_list = NULL` before calling `tls_strp_flush_anchor_copy()`. This creates a state inconsistency where: - The `full_len` field is not reset in `tls_strp_flush_anchor_copy()` - The frag_list is set to NULL - On the next call to `tls_strp_read_sock()`, the code expects frag_list to be valid based on `full_len` being non-zero 3. **Security impact**: - This can be triggered by memory allocation failures (which can be induced by resource exhaustion) - Results in a kernel panic/crash (DoS) - The vulnerability is in the TLS receive path, affecting network-facing code 4. **Exploitability**: While memory allocation failures are not directly controlled by attackers, they can be influenced through resource exhaustion attacks, making this a potential DoS vector. 5. **Similar to CVE-assigned commits**: This follows the pattern of other CVE-assigned commits that fix NULL pointer dereferences in network-facing kernel code, particularly those that can cause kernel panics. The fix simply moves the `shinfo->frag_list = NULL` assignment to after the memory allocation loop, ensuring that if allocation fails and `tls_strp_flush_anchor_copy()` is called, the state remains consistent. |
| dd24f87f65c95 ublk: fix dead loop when canceling io command |
| - [sasha] Based on my analysis, **YES**, this commit should be assigned a CVE. This fix addresses a denial-of-service vulnerability in the ublk driver where: 1. **The vulnerability causes an infinite loop/deadlock** in kernel space during command cancellation, as shown in the code change where the fix adds `&& req->tag == tag` to prevent checking stale requests. 2. **Security impact**: The deadlock prevents proper cleanup of ublk devices and resources, which can: - Block kernel threads indefinitely - Prevent device cleanup and unmounting - Lead to resource exhaustion - Cause system instability 3. **Exploitability**: The ublk driver supports unprivileged device creation (UBLK_F_UNPRIVILEGED_DEV flag), meaning regular users can potentially trigger this deadlock condition, making it a security concern. 4. **Root cause**: The previous fix (f40139fde527) introduced a check that could evaluate stale request data, where `req->tag` might not match the actual tag being canceled, causing the cancellation logic to skip commands that should be canceled, resulting in the infinite loop. The one-line fix (`&& req->tag == tag`) ensures that only the correct, non-stale request is considered when deciding whether to skip cancellation, preventing the deadlock scenario. This matches the pattern of similar ublk CVEs that fix race conditions and use-after-free issues in the same subsystem. |
| d9ec73301099e fs/eventpoll: fix endless busy loop after timeout has expired |
| - [sasha] Based on my analysis, here's my determination: **YES** - This commit should be assigned a CVE. Here's my reasoning: 1. **Denial of Service vulnerability**: The commit message explicitly states that the bug causes "a soft lockup, RCU stalls and deadlocks, inflicting severe headaches to the whole system." This is a clear denial of service condition. 2. **Unprivileged attack vector**: The proof-of-concept code shows that any unprivileged user can trigger this bug with a simple program that: - Creates an epoll instance (no special privileges required) - Adds stdin (fd 0) to the epoll set - Calls epoll_pwait2 with a 1 nanosecond timeout 3. **Kernel-level infinite loop**: The bug causes the kernel to enter an endless busy loop in ep_poll(), consuming CPU resources and potentially causing system-wide impact including: - Soft lockups (kernel threads stuck) - RCU stalls (affecting kernel synchronization) - Potential deadlocks 4. **Easy to exploit**: The PoC is trivial - just a few lines of code that any unprivileged user can run. 5. **System-wide impact**: Unlike bugs that only affect the calling process, this creates kernel-level busy loops that can impact the entire system's stability and availability. The security impact is similar to other CVE-assigned eventpoll bugs like the ones shown in the reference commits that deal with race conditions and use-after-free issues. This bug allows unprivileged local users to cause a denial of service condition, which warrants CVE assignment. |
| 578e1b96fad74 HID: bpf: abort dispatch if device destroyed |
| - [sasha] Based on my analysis of the commit, this should be assigned a CVE. Here's my reasoning: **YES** This commit fixes a use-after-free vulnerability in the HID BPF subsystem. The vulnerability occurs due to a race condition where: 1. **Use-after-free vulnerability**: The bug allows access to a cleaned-up SRCU structure (`hdev->bpf.srcu`) after `hid_bpf_destroy_device()` has been called and `cleanup_srcu_struct()` has freed the SRCU resources. 2. **Exploitable race condition**: The commit message clearly describes a race where LED worker threads can still call `dispatch_hid_bpf_output_report()` or `dispatch_hid_bpf_raw_requests()` after device destruction, leading to: - Access to freed memory (`srcu_read_lock(&hdev->bpf.srcu)` on destroyed SRCU) - Potential memory corruption as it "corrupts whatever is on the address calculated by SRCU" 3. **Security impact**: The vulnerability can lead to: - Memory corruption - Potential kernel crashes (as evidenced by the x86 percpu change making it access "not-present pages") - Possible privilege escalation through controlled memory corruption 4. **Affected versions**: The vulnerability affects kernels from v6.11 onwards (when commit 8bd0488b5ea5 was introduced). 5. **Triggering conditions**: The bug requires specific but achievable conditions: - A HID device with LEDs enabled - A driver without `hid_ll_driver->request()` implemented (like logitech-djreceiver) - Device unplugging to trigger the race The fix adds proper checks (`if (unlikely(hdev->bpf.destroyed))`) in all dispatch functions to prevent accessing the SRCU after destruction, which is a clear security boundary enforcement. |
| 2468b0e3d5659 LoongArch: Prevent cond_resched() occurring within kernel-fpu |
| - [sasha] Based on my comprehensive analysis of this commit, here is my determination: **YES** - This commit should be assigned a CVE. Here's my reasoning: 1. **Security Impact**: The commit fixes a kernel panic/crash vulnerability that can be triggered when FPU operations are used in kernel mode with certain kernel configurations (CONFIG_PREEMPT_NONE/CONFIG_PREEMPT_VOLUNTARY). 2. **The Bug**: When `preempt_disable()` is just a barrier (in non-preempt count configs), `cond_resched()` can still trigger a context switch that modifies CSR.EUEN register, causing a `do_fpu()` exception within kernel FPU critical sections. As shown in the exception handler, this results in `die_if_kernel("do_fpu invoked from kernel context!", regs)` - a kernel panic. 3. **Attack Vector**: This can be triggered through legitimate kernel code paths like the AMD GPU driver's display code (`dcn32_calculate_wm_and_dlg()`) when it allocates memory with `GFP_KERNEL` inside FPU sections, which can trigger `cond_resched()`. 4. **Similar CVE Pattern**: The similar commits shown (CVE Status: YES) also deal with: - Preventing sleeping/scheduling in atomic contexts - Fixing race conditions that can cause kernel crashes - Issues with interrupt/preemption handling in critical sections 5. **Exploitability**: While this appears to require specific hardware (AMD GPU) and kernel configuration, it represents a denial-of-service vulnerability where unprivileged code that can trigger GPU operations could potentially crash the kernel. 6. **Stable Backport**: The commit is marked with `Cc: stable@vger.kernel.org`, indicating it's a fix for a serious issue that needs backporting. The vulnerability allows triggering a kernel panic through normal kernel operations when specific kernel configurations are used, making it a legitimate security issue deserving of a CVE assignment. |
| 72c7d62583ebc dma-buf: insert memory barrier before updating num_fences |
| - [sasha] Based on my analysis, I can now provide my assessment: **YES** - This commit should be assigned a CVE. The commit fixes a critical NULL pointer dereference vulnerability with clear security implications: 1. **Memory Barrier Issue**: The commit message explicitly states that `smp_store_mb()` inserts a memory barrier AFTER the store operation, not before. This is crucial because the original code comment says "pointer update must be visible before we extend the num_fences", but `smp_store_mb()` was doing the opposite. 2. **Race Condition Leading to NULL Pointer Dereference**: The incorrect memory barrier ordering creates a race where: - Thread A: Sets the fence pointer with `dma_resv_list_set(fobj, i, fence, usage)` - Thread A: Updates `num_fences` with `smp_store_mb(fobj->num_fences, count)` - Thread B (concurrent reader): Can see the incremented `num_fences` BEFORE seeing the fence pointer due to reordering - Thread B: Attempts to access an uninitialized fence slot, leading to NULL pointer dereference 3. **Security Impact**: This vulnerability can cause: - System crashes (kernel panic) - Potential for exploitation if an attacker can trigger the race condition - Memory corruption in kernel space 4. **Similar Pattern to CVE-Assigned Commits**: This follows the same pattern as the similar commits shown that received CVEs - fixing NULL pointer dereferences in kernel subsystems that handle concurrent access. 5. **The Fix**: The commit correctly replaces `smp_store_mb()` with `smp_wmb()` followed by the store, ensuring the fence update is visible BEFORE `num_fences` is incremented, preventing the race condition. The fact that this was marked for stable kernels (`CC: stable@vger.kernel.org`) and fixes a specific commit (`Fixes: a590d0fdbaa5`) further confirms this is a security-relevant bug fix that warrants a CVE assignment. |
| d2062cc1b1c36 x86/sev: Do not touch VMSA pages during SNP guest memory kdump |
| - [sasha] Let me check the commit message again and analyze the security impact: Based on my analysis of the commit and the code changes, my decision is: **YES** This commit should be assigned a CVE for the following reasons: 1. **Security Impact - Guest Hang/DoS**: The commit fixes a bug that causes "guest softlockup/hang" when touching VMSA pages during kdump. This represents a denial-of-service vulnerability where accessing protected memory pages leads to unrecoverable #NPF/RMP faults. 2. **Memory Protection Violation**: The bug involves improper access to VMSA (VM Save Area) pages which are security-critical pages containing encrypted guest state. VMSA pages are marked as busy/in-use when a vCPU is running, and accessing them improperly violates the security model of SEV-SNP. 3. **Crash During Security-Sensitive Operation**: The issue occurs during kdump (kernel crash dump), which is a critical recovery mechanism. The bug prevents proper crash dump collection, potentially hiding security incidents or making forensic analysis impossible. 4. **Similar to CVE-assigned Commits**: Looking at the similar commits, the "mm: gup: stop abusing try_grab_folio" commit was assigned a CVE for causing kernel warnings and failures when pinning memory in SEV VMs. This commit has similar characteristics - SEV-SNP memory handling issues leading to system failures. 5. **Fixes a Regression**: The bug was introduced by commit 3074152e56c9 ("x86/sev: Convert shared memory back to private on kexec"), meaning working systems were broken by that change. The code changes show the fix involves: - Properly shutting down APs (Application Processors) before touching their VMSA pages - Marking running vCPU's VMSA page as offline to exclude it from makedumpfile - Using AP_DESTROY GHCB calls to ensure APs are kicked out of guest mode This is clearly a security-relevant fix that prevents system hangs and ensures proper memory protection boundaries are maintained in SEV-SNP environments. |
| fca280992af8c dmaengine: ti: k3-udma: Add missing locking |
| - [sasha] Based on my analysis of this commit, here's my assessment: **YES** This commit should be assigned a CVE for the following reasons: 1. **Race Condition in DMA Operations**: The code changes show a missing lock protection in `udma_check_tx_completion()` function when accessing `uc->desc` and calling functions like `udma_is_desc_really_done()` and `udma_start()`. The warning indicates that `udma_start()` calls `vchan_next_desc()` which requires holding `vc->lock` (as shown by the `lockdep_assert_held(&vc->lock)` check at line 169 of virt-dma.h). 2. **Concurrent Access Without Synchronization**: The workqueue function `udma_check_tx_completion()` runs in a separate context and accesses shared data structures (`uc->desc`, `uc->tx_drain.residue`, etc.) without holding the required lock. This can race with other code paths that modify these structures, such as the IRQ handler `udma_ring_irq_handler()` which does hold the lock when accessing the same data. 3. **Potential Security Impact**: Race conditions in DMA drivers can lead to: - Use-after-free vulnerabilities if descriptors are freed while being accessed - Data corruption or memory corruption if DMA operations are started with inconsistent state - Potential privilege escalation if corrupted DMA operations access unintended memory regions 4. **Lockdep Warning Validates the Issue**: The lockdep warning in the commit message confirms this is a real locking violation detected by the kernel's runtime lock validator, not just a theoretical issue. 5. **Long-standing Bug**: The issue has existed since the driver was initially introduced in 2019 (commit 25dcb5dd7b7c), affecting all kernel versions with this driver until the fix. The fix properly adds `spin_lock_irqsave(&uc->vc.lock, flags)` around the critical sections that access shared channel state, preventing the race condition. |
| 46a5cca76c76c dmaengine: idxd: fix memory leak in error handling path of idxd_alloc |
| - [sasha] Based on my analysis of this commit and comparison with similar CVE-assigned commits, here's my determination: **YES** This commit should be assigned a CVE for the following reasons: 1. **Memory Leak in Error Path**: The commit fixes a memory leak where allocated memory for `idxd` structure, ida allocation, and `opcap_bmap` bitmap are not properly freed when `dev_set_name()` fails in the `idxd_alloc()` function. 2. **Similar to CVE-Assigned Commits**: The pattern matches other memory leak fixes in the same driver that were assigned CVEs: - Similar commits like "dmaengine: idxd: fix memory leak in error handling path of idxd_setup_engines" and others in the same series were likely assigned CVEs - The fixes follow the same pattern of adding proper cleanup in error paths 3. **Security Impact**: Memory leaks in kernel drivers can lead to: - Resource exhaustion over time - Potential denial of service if an attacker can trigger the error path repeatedly - The issue occurs during device initialization/probe, which could be triggered by device hot-plug operations 4. **Specific Resources Leaked**: - The main `idxd` structure (kzalloc'd memory) - An IDA allocation (`idxd->id` from ida_alloc) - A bitmap allocation (`idxd->opcap_bmap` from bitmap_zalloc_node) 5. **Long-standing Issue**: The bug was introduced in September 2022 (commit a8563a33a5e2) and affects multiple kernel versions, indicating a significant exposure window. The fix properly adds error handling labels (`err_name`, `err_opcap`, `err_ida`) and ensures all allocated resources are freed in reverse order when an error occurs, preventing the memory leak. |
| a409e919ca321 dmaengine: idxd: Refactor remove call with idxd_cleanup() helper |
| - [sasha] Based on my analysis, this commit should be assigned **YES** for a CVE. Here's my explanation: This commit fixes a **reference count leak** (missing put_device() calls) for idxd groups, engines, and work queues. The issue is clearly stated in the commit message: "this also fixes the missing put_device() for idxd groups, engines and wqs." The security implications are: 1. **Resource Leak**: Without calling put_device() on groups, engines, and wqs during device removal, the kernel fails to properly decrement reference counts. This prevents these kernel objects from being freed. 2. **Memory Exhaustion**: Over time, with repeated module loading/unloading or device hotplug operations, this leak could accumulate and lead to memory exhaustion, potentially causing a denial of service. 3. **Pattern matches CVE-worthy issues**: Looking at the similar commits: - The "Prevent use after free on completion memory" commit received a CVE for a use-after-free issue - The "Avoid unnecessary destruction of file_ida" commit received a CVE for improper resource management - This commit similarly fixes improper resource management (reference count leak) The code analysis shows: - In `idxd_init_groups()`, `idxd_init_engines()`, and `idxd_setup_wqs()`, `device_initialize()` is called on conf_dev structures - The cleanup functions `idxd_clean_groups()`, `idxd_clean_engines()`, and `idxd_clean_wqs()` properly call `put_device()` - However, the original `idxd_remove()` function was not calling these cleanup functions, leading to leaked device references This is a clear resource management vulnerability that could impact system stability and availability. |
| 4480912f3f8b8 accel/ivpu: Move parts of MMU event IRQ handling to thread handler |
| - [sasha] **YES** This commit fixes a denial-of-service vulnerability where the Intel VPU (IVPU) driver's MMU event interrupt handler could loop infinitely, causing system hangs. The vulnerability occurs because: 1. The MMU event handler previously tried to disable further event recording by removing the 'R' bit from the context descriptor directly in interrupt context 2. This change requires configuration invalidation and sync commands which take significant time 3. During this time window, the MMU could continue generating new events faster than they could be processed, leading to an infinite loop in the interrupt handler The fix moves the time-consuming operations (disabling event recording, configuration invalidation, and sync) to a threaded handler via `ivpu_mmu_disable_ssid_events()` and implements proper synchronization through `ivpu_mmu_evtq_disable()` and `ivpu_mmu_discard_events()` to ensure the MMU stops generating events before updating the consumer index. This is a classic interrupt storm DoS vulnerability that could be triggered by unprivileged local users with access to the VPU device, making the system unresponsive and requiring a reboot to recover. |
| 683e9fa1c885a accel/ivpu: Flush pending jobs of device's workqueues |
| - [sasha] Now let me analyze the current commit that fixes the referenced commit bc3e5f48b7ee: **YES** - This commit should be assigned a CVE. The commit fixes two critical issues that have security implications: 1. **Context-abort race condition**: The commit fixes a bug where canceling context-abort work could leave a job executing that is causing translation faults. This creates a **denial of service vulnerability** where: - A job continues to execute despite causing translation faults - This leads to additional TDRs (Timeout Detection and Recovery) - The system enters an incorrect state that can affect stability and availability 2. **DCT (Duty-Cycle Throttling) bypass**: The commit fixes an issue where canceling DCT request handling could prevent the device from adjusting to external frequency requests. This could potentially be exploited to: - Bypass thermal/power management controls - Cause the device to operate outside safe parameters - Potentially damage hardware or cause system instability The key security-relevant change is switching from `cancel_work_sync()` to `flush_work()`: ```c - cancel_work_sync(&vdev->irq_ipc_work); - cancel_work_sync(&vdev->irq_dct_work); - cancel_work_sync(&vdev->context_abort_work); + flush_work(&vdev->irq_ipc_work); + flush_work(&vdev->irq_dct_work); + flush_work(&vdev->context_abort_work); ``` This ensures that pending work is **completed** rather than **canceled**, preventing the driver from being left in an incorrect state that could be exploited for denial of service attacks. Similar to the CVE-assigned commits in the examples (deadlock fixes and NULL pointer dereference fixes), this commit addresses a condition that can leave the system in an exploitable state, making it worthy of a CVE assignment. |
| f81b33582f933 RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug |
| - [sasha] **YES** - This commit should be assigned a CVE. The race condition between `rxe_cq_post()` and the completion handler accessing shared producer/consumer indices without proper synchronization is a security vulnerability because: 1. **Memory Safety Risk**: Corrupted queue indices can lead to out-of-bounds memory access 2. **DoS Potential**: Queue mismanagement can cause RDMA operations to fail or hang 3. **Data Integrity**: Missing or duplicate completions can corrupt application data flows 4. **Kernel Stability**: Queue state corruption could potentially crash the kernel The fix properly adds spinlock protection (`cq_lock`) around all accesses to the shared indices, ensuring atomic updates and preventing the race condition. |
