| bbfe756dc306 fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio() |
| - [sasha] YES. This commit should be assigned a CVE because it fixes a denial-of-service vulnerability. The issue occurs in the EROFS filesystem's I/O path where erofs_onlinefolio_split() was called before bio_add_folio(). If bio_add_folio() failed, the code would retry but call erofs_onlinefolio_split() again without a matching erofs_onlinefolio_end(), leaving the folio locked forever and causing threads to hang in folio_wait_bit_common(). This condition became more easily triggerable after commit 9f74ae8c9ac9 reduced bio capacity from 256 to 16 folios. Unprivileged users could trigger this via simple file operations like posix_fadvise(), making it a significant availability impact vulnerability. |
| c23c03bf1faa firmware: arm_scmi: Fix timeout checks on polling path |
| - [sasha] YES. This commit fixes a race condition that could lead to a system hang or denial of service. The issue affects the ARM System Control and Management Interface (SCMI) driver's polling mechanism, which is used for communication between application processors and system control processors. The bug allows a race condition where the polling timeout check incorrectly times out when the thread is preempted, even if the operation would have succeeded. This can cause important system operations to fail erroneously, potentially causing system instability. The code changes add additional checks to verify whether the polling actually completed successfully, rather than relying solely on elapsed time checks. Similar commits that addressed potential deadlocks or race conditions in critical subsystems (like Similar Commit 2 and Similar Commit 4) were assigned CVEs because they could lead to denial of service conditions. |
| 42420c50c68f s390/pci: Fix missing check for zpci_create_device() error return |
| - [sasha] YES. This commit should be assigned a CVE because it fixes a critical memory corruption vulnerability in the kernel's PCI subsystem on s390 platforms. The bug occurs in `__clp_add()` where an error pointer returned from `zpci_create_device()` is not checked before being added to a linked list with `list_add_tail()`. Attempting to use an error pointer as a valid structure pointer can lead to memory corruption and system crashes, creating a potential denial-of-service vulnerability. Looking at similar commits marked with "CVE Status: YES", particularly Similar Commit 2 (PCI: s390: Fix use-after-free of PCI resources), this bug follows a similar pattern of memory mismanagement in the s390 PCI subsystem. Like that CVE, this vulnerability affects kernel memory safety and could be triggered through PCI operations. The fix is simple but critical - adding a proper error check before dereferencing the pointer, preventing memory corruption and potential system crashes. |
| 023c1f2f0609 wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation |
| - [sasha] YES. This commit fixes an out-of-bounds access vulnerability in the multi-link element defragmentation process in the Linux kernel's WiFi subsystem. The bug occurs in `cfg80211_defrag_mle()` where an incorrect calculation (`ielen - sizeof(*mle) + mle->datalen`) is used to determine the remaining buffer length when iterating through element fragments. This calculation could lead to accessing memory beyond the bounds of the allocated buffer when the multi-link element or its fragments are at the end of the buffer. The fix properly calculates the remaining buffer length by using `ie + ielen - mle->data - mle->datalen` instead. This vulnerability could potentially be exploited by sending specially crafted WiFi frames to trigger an out-of-bounds read, which might lead to information disclosure, crashes, or potential code execution. Similar buffer overflow/out-of-bounds issues in the WiFi subsystem have received CVEs previously (as seen in the reference commits). |
| 05a2538f2b48 s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFs |
| - [sasha] YES. This commit fixes a double reference counting bug in s390's PCI subsystem that could lead to a use-after-free vulnerability. The commit message explicitly states it can "cause a use after free if the struct pci_dev is released in an unexpected state." Looking at the code changes, the fix removes a duplicate `pci_dev_put()` call that was incorrectly left in place when error handling code was reorganized. This type of reference counting error is security-sensitive as it can lead to memory corruption, crashes, or potential exploitation through use-after-free scenarios. Similar commits affecting PCI subsystems (like commits 1, 2, and 4 in the examples) were assigned CVEs. The vulnerability is particularly concerning in virtualized environments where PCI passthrough is used with SR-IOV, as it could potentially be triggered by guest VMs with access to PCI devices. |
| 53e3e5babc09 ksmbd: prevent rename with empty string |
| - [sasha] YES. This commit fixes a security vulnerability that deserves a CVE. This is a kernel memory corruption vulnerability in the KSMBD filesystem module. The issue occurs when a client sends an empty newname string to the server during rename operations. According to the commit message, this causes "a kernel oops from d_alloc" which indicates memory corruption in the kernel space. The fix adds validation to reject empty strings: ```c if (*name == '\0') { kfree(name); return ERR_PTR(-EINVAL); } ``` This is a remotely exploitable denial of service vulnerability at minimum, as attackers could trigger kernel panics by sending specifically crafted SMB requests with empty rename strings. The potential for privilege escalation cannot be ruled out since kernel memory corruption can sometimes be leveraged for more severe attacks. |
| 0ca6df4f40cf ksmbd: prevent out-of-bounds stream writes by validating *pos |
| - [sasha] YES. This commit fixes a critical security vulnerability that should receive a CVE assignment. The code change addresses an out-of-bounds write vulnerability in ksmbd_vfs_stream_write() where the *pos parameter (write offset) wasn't properly validated against the stream buffer length (v_len). This allowed writing data beyond the allocated buffer boundaries with memcpy(&stream_buf[*pos], buf, count). The fix adds an explicit check: if (v_len <= *pos) return -EINVAL, preventing out-of-bounds memory access. This vulnerability is nearly identical to previously assigned CVEs (Similar Commits 1-5) which all fixed boundary validation issues in ksmbd. The potential impact includes kernel memory corruption, denial of service, and possibly remote code execution through a network-accessible service. |
| 36991c1ccde2 ksmbd: Fix UAF in __close_file_table_ids |
| - [sasha] YES. This commit fixes a use-after-free vulnerability in the Linux kernel's KSMBD module. The code changes address a race condition in `__close_file_table_ids` where a file could be accessed after being freed if one thread destroys the file via `__ksmbd_close_fd` while another thread holds a reference. The fix implements proper locking using `ft->lock` to ensure thread safety when removing files from the file table, similar to other CVE-assigned commits for UAF issues in KSMBD (e.g., ksmbd_sessions_deregister). |
| 6beb6835c1fb openvswitch: Fix unsafe attribute parsing in output_userspace() |
| - [sasha] YES. This commit fixes a security vulnerability that should receive a CVE. The issue involves unsafe Netlink attribute parsing in the Open vSwitch kernel module's output_userspace() function. The key problem is that the original code used manual iteration through Netlink attributes without proper bounds checking: ```c for (a = nla_data(attr), rem = nla_len(attr); rem > 0; a = nla_next(a, &rem)) ``` This code relies on nla_next() to advance through attributes, but doesn't verify that each attribute is valid before accessing it. An attacker could craft malformed Netlink messages with invalid attribute lengths, potentially causing out-of-bounds memory access or buffer overflows. The fix replaces this unsafe pattern with the safer nla_for_each_nested() macro, which provides proper bounds checking and validation of each attribute: ```c nla_for_each_nested(a, attr, rem) ``` This vulnerability is similar to other Netlink attribute validation issues that received CVEs (like CVEs for Similar Commits 1, 2, and 3 in the reference list). The impact could range from denial-of-service to potential privilege escalation, since the code runs in kernel space. Given the pattern of labeling similar attribute validation fixes as CVEs, this one should receive the same treatment. |
| eb4447bcce91 ksmbd: fix memory leak in parse_lease_state() |
| - [sasha] YES. This commit fixes a memory leak vulnerability in the ksmbd file server that should be assigned a CVE. When the bounds checks fail in parse_lease_state(), the function was returning NULL without freeing the previously allocated lease_ctx_info structure, causing a memory leak. An attacker could exploit this by repeatedly sending malformed SMB lease requests that trigger these boundary checks, eventually leading to resource exhaustion and denial of service. While this is not a memory corruption vulnerability, resource exhaustion issues in network-facing services are security vulnerabilities that warrant CVEs. The fix properly frees the allocated memory before returning NULL in error cases. |
| 376947861013 sch_htb: make htb_deactivate() idempotent |
| - [sasha] YES. This commit fixes a security vulnerability that should receive a CVE. The issue is a NULL pointer dereference in htb_next_rb_node() in the Linux kernel's network traffic control subsystem. The bug can cause kernel panic/system crashes (denial of service) when a specific sequence of operations occurs in the HTB queueing discipline code. The code change in htb_next_rb_node() explicitly adds a NULL check (`if (*n)`) before dereferencing the pointer, confirming this was a real NULL pointer dereference vulnerability. Similar issues in networking components have received CVEs, as seen in the reference examples (particularly commits 1, 2, and 5). |
| 4397684a292a virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable() |
| - [sasha] YES. This commit fixes a memory leak in virtnet_xsk_pool_enable() that could lead to denial of service. The code allocates memory for xsk_buffs but fails to free it when subsequent operations fail. The fix adds proper cleanup in the error path at err_free_buffs. This memory leak is similar to other XSK-related memory leaks that received CVEs (examples 3 and 4), as it could be triggered repeatedly to exhaust system memory resources. |
| 511e64e13d8c can: gw: fix RCU/BH usage in cgw_create_job() |
| - [sasha] After analyzing the provided code changes in the "can: gw: fix RCU/BH usage in cgw_create_job()" commit, I can determine: YES, this commit should be assigned a CVE. Explanation: 1. The commit fixes a race condition in the CAN gateway module where modification data was improperly protected during updates. The issue occurs when updating modification rules where using `local_bh_disable()` was only safe on uniprocessor systems but would cause race conditions on multiprocessor systems. 2. Key security issues identified: - The code previously used `local_bh_disable()/local_bh_enable()` for synchronization when updating `gwj->mod` in `cgw_create_job()`, which is insufficient for proper protection on multiprocessor systems. - The fix changes `struct cf_mod mod` to `struct cf_mod __rcu *cf_mod` and implements proper RCU (Read-Copy-Update) protection mechanisms. 3. This race condition could potentially be exploited to cause: - Memory corruption during modification updates - Use-after-free conditions when accessing the modification structure - System crashes (denial of service) 4. The issue is similar to the "Similar Commit 1" and "Similar Commit 3" examples in your reference, both of which received CVEs. Specifically, it involves improper RCU protection like in "Similar Commit 1" which fixed improper annotation for RCU-protected items. 5. The `can_can_gw_rcv()` function accesses modification data during packet processing, which could be triggered by sending specially crafted CAN frames to the interface, making this potentially exploitable remotely if an attacker has access to the CAN bus. This is a clear case of a memory safety issue in kernel code with potential for exploitation, similar to previously assigned CVEs in network subsystems. |
| 35076d2223c7 erofs: ensure the extra temporary copy is valid for shortened bvecs |
| - [sasha] YES. This commit should be assigned a CVE. The bug affects the EROFS filesystem's compressed data deduplication feature and can lead to data corruption. The issue occurs when multiple logical extents reference the same compressed physical cluster with shortened bvecs, where extra temporary buffers weren't being properly preserved for later use in z_erofs_fill_other_copies(). The code changes show that this was addressed by replacing the "multibases" flag with a new "keepxcpy" flag and improving the logic to properly identify cases of shortened bvecs that require preservation of temporary buffers. Even though this requires a specific configuration (compressed data deduplication enabled with "-Ededupe"), the risk of filesystem corruption constitutes a security vulnerability as it can lead to denial of service conditions and data loss. |
| e34090d7214e ipvs: fix uninit-value for saddr in do_output_route4 |
| - [sasha] YES. This commit should be assigned a CVE. The fix addresses an uninitialized value read in the Linux kernel's IPVS module's do_output_route4() function, where *saddr is accessed without proper initialization. Similar to CVE-assigned examples, this bug allows reading uninitialized kernel memory in network-facing code. The code changes show a clear redesign of the function parameter from *saddr (which was being both read from and written to) to *ret_saddr (which is only written to). This prevents potential information leakage of kernel memory contents through network packets and eliminates a condition where routing decisions could be based on uninitialized values, potentially causing denial of service. |
| 8478a729c046 netfilter: ipset: fix region locking in hash types |
| - [sasha] The file I've read doesn't match the commit I'm looking for. Let me analyze this based on the information provided in the question. YES. This commit should be assigned a CVE. The commit fixes a race condition in the Linux netfilter ipset hash types implementation that could lead to kernel memory corruption. The problem is in the `ahash_region()` macro, which incorrectly calculated which region lock belongs to a hash bucket. The fix changes: ```c #define ahash_region(n, htable_bits) - ((n) % ahash_numof_locks(htable_bits)) + ((n) / jhash_size(HTABLE_REGION_BITS)) ``` This calculation error would cause potential concurrent access to the same data by the garbage collector and element addition code when using hash sets with timeouts. The incorrect modulo operation meant multiple hash buckets could be assigned to the wrong region lock, leading to race conditions where different operations could manipulate the same memory without proper synchronization. Looking at the similar CVE-assigned commits provided (especially Commit 2, 3, and 5), this exhibits similar characteristics: 1. It fixes a race condition in kernel memory handling 2. It could lead to memory corruption in the kernel 3. It references the same core functionality fixed in CVE-assigned commit f66ee0410b1c 4. It deals with proper locking mechanisms in multiprocessing environments A malicious actor could potentially exploit this by timing operations on ipset data structures to trigger concurrent memory access, leading to kernel crashes (denial of service) or potentially even privilege escalation through memory corruption. The issue is severe as it affects a core networking component and could be triggered from unprivileged contexts if the attacker can manipulate ipset operations with specific timing. |
| c43272299488 bpf: Scrub packet on bpf_redirect_peer |
| - [sasha] YES. This commit fixes a security vulnerability that allows information leakage between network namespaces. When bpf_redirect_peer redirects packets to a device in another namespace, the skb (socket buffer) is not properly scrubbed, allowing sensitive information (like XFRM state) to cross namespace boundaries. The fix adds skb_scrub_packet(skb, false) to properly clean this information. This violates the isolation principle and could lead to privilege escalation in containerized environments, as data from privileged namespaces could be accessed. Similar security issues have received CVEs (like the similar commit #4), and network namespace isolation is a critical security boundary in containerized environments. |
| 2dc2bd571115 net: dsa: b53: fix toggling vlan_filtering |
| - [sasha] YES. This commit fixes a security vulnerability that could lead to VLAN traffic leaks. The issue arises when toggling between VLAN filtering modes, where VLAN configurations weren't properly maintained or applied. The key security issues: 1. The patch adds proper tracking of VLAN filtering state in the device (`dev->vlan_filtering`) and port PVID values (`dev->ports[port].pvid`), which were previously not properly maintained across mode changes. 2. The code now separates when VLAN settings should be stored in memory versus applied to hardware with checks like: ```c if (!dev->vlan_filtering) return 0; ``` before hardware operations. 3. Similar to the "net: dsa: mt7530: fix VLAN traffic leaks" commit (CVE: YES), this fix prevents traffic from leaking between VLANs when switching between filtering modes. When VLAN filtering was toggled, the lack of proper state tracking could have allowed traffic to leak between VLANs that should be isolated, breaking network segmentation - a clear security vulnerability. |
| f34343cc11af fbnic: Fix initialization of mailbox descriptor rings |
| - [sasha] YES This commit fixes a security vulnerability that should be assigned a CVE. The issue involves improper initialization of mailbox descriptor rings in the fbnic driver, which could result in DMAR (DMA Remapping) faults due to memory access failures. The key security implications are: 1. Memory Safety Violation: The original code incorrectly orders memory operations when initializing descriptor rings. The firmware could attempt to access memory with the upper 32 bits of addresses set to 0, which could lead to accessing incorrect memory regions. 2. Potential Denial of Service: DMAR faults triggered by these invalid memory accesses could cause system instability or crashes, especially during mailbox shutdown operations. 3. Similar to Known CVEs: This resembles other memory handling issues that received CVEs, particularly Similar Commit 2 and Similar Commit 3 which address memory corruption vulnerabilities in mailbox or message handling. 4. The fix creates a new `__fbnic_mbx_invalidate_desc` function that ensures the lower 32 bits (containing validity flags) are written before clearing the upper 32 bits, preventing the race condition where firmware might access a descriptor with valid flags but corrupted address data. The commit specifically notes this "will likely result in DMAR faults due to write access failures" - indicating a serious system stability issue that would warrant a CVE similar to other memory handling CVEs in the kernel. |
| 11cdb506d0fb Input: mtk-pmic-keys - fix possible null pointer dereference |
| - [sasha] YES. This commit should be assigned a CVE because it fixes a null pointer dereference vulnerability in the Linux kernel's input subsystem. The key change replaces accessing potentially NULL pointers through `keys->keys[MTK_PMIC_*KEY_INDEX].regs` with the safer approach of using `®s->keys_regs[MTK_PMIC_*KEY_INDEX]`, which prevents kernel panics when a button is disabled in device tree. This vulnerability could lead to denial of service attacks similar to other null pointer dereference issues in the reference commits that received CVEs. |
| 98698ca0e587 staging: bcm2835-camera: Initialise dev in v4l2_dev |
| - [sasha] YES, this commit should be assigned a CVE. This is a null pointer dereference vulnerability in the Linux kernel's bcm2835-camera driver (used in Raspberry Pi devices). The issue occurs when dev->v4l2_dev.dev is passed to vchiq_mmal_init without being initialized first. As stated in the commit message, "nothing initialised dev->v4l2_dev, so we got a NULL pointer dereference." Key factors supporting a CVE: 1. It's a kernel null pointer dereference that can cause system crashes 2. The pattern is similar to Similar Commit 3 and 5 (both with CVE Status: YES) 3. The fix explicitly adds initialization (dev->v4l2_dev.dev = &device->dev;) 4. It affects a widely used driver in Raspberry Pi devices 5. The commit is marked with "Cc: stable@vger.kernel.org" indicating high severity This vulnerability allows unprivileged users to cause a denial of service by triggering a kernel crash when using the camera interface. |
| fea4e317f9e7 x86/mm: Eliminate window where TLB flushes may be inadvertently skipped |
| - [sasha] YES This commit should be assigned a CVE based on the following analysis: 1. **TLB Security Issue**: The commit fixes a bug where TLB flushes are inadvertently skipped during memory management context switching. This creates a window where stale TLB entries could remain active when they should have been flushed. 2. **Similar CVE Precedent**: Similar commits #2 and #4 that fix TLB flush issues (specifically "x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs") were assigned CVEs. This commit addresses a comparable issue in the TLB flush mechanism. 3. **Critical Code Path**: The bug affects `should_flush_tlb()` during the critical window between `load_new_mm_cr3()` and writing to `loaded_mm`. The fix adds a check for `LOADED_MM_SWITCHING` state: ```c if (loaded_mm == LOADED_MM_SWITCHING) return true; ``` 4. **Memory Barrier Addition**: The code adds an `smp_rmb()` memory barrier to ensure proper ordering of memory operations, indicating this is addressing a potential race condition with security implications. 5. **Stable Backport**: The commit is marked for stable kernels (`cc: stable@vger.kernel.org`) and has a specific "Fixes:" tag, indicating it addresses a significant issue that needs to be backported to older kernel versions. While the commit message doesn't explicitly mention security implications, TLB flush bugs can lead to unauthorized memory access by allowing processes to retain stale mappings to memory pages they should no longer have access to. |
| be6e843fc51a mm/huge_memory: fix dereferencing invalid pmd migration entry |
| - [sasha] YES This commit fixes a security vulnerability that results in an invalid memory access (page fault) that could potentially be exploited to cause system crashes or worse. The evidence for assigning a CVE includes: 1. **Security-relevant crash** - The commit message shows a concrete bug with a call trace indicating a page fault: - "BUG: unable to handle page fault for address: ffffea60001db008" - This occurs in kernel memory during split_huge_pmd_locked execution 2. **Valid security impact** - The vulnerability involves dereferencing an invalid PMD migration entry during THP (Transparent Huge Pages) migration, leading to an invalid address access that crashes the kernel. This matches the pattern of Similar Commit 4/5 which received CVEs for memory management race conditions. 3. **Fixes a regression** - The commit clearly identifies it as fixing a regression introduced by "84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path")", indicating a previously introduced vulnerability. 4. **Root cause identification** - The code change shows the vulnerability occurs when checking `folio != pmd_folio(*pmd)` without first verifying if the PMD is a migration entry. The fix adds a `pmd_migration` check before calling `pmd_folio()` to prevent the invalid access. 5. **Stable backport requested** - The presence of `Cc: <stable@vger.kernel.org>` indicates this is a serious bug that needs backporting to stable kernels, typical for security vulnerabilities. 6. **Memory corruption category** - Like Similar Commits 4 and 5 (which received CVEs), this is a race condition in memory management code that can lead to invalid memory operations. The vulnerability involves KASAN-detectable memory access violations in core MM code. The added code explicitly prevents the invalid dereference by checking if the PMD is a migration entry before attempting to access it: ```c +if (folio && (pmd_migration || folio != pmd_folio(*pmd))) ``` This prevents the kernel from trying to dereference a migration entry as if it were a normal PMD, which would cause the invalid memory access shown in the bug report. |
| 95567729173e mm/userfaultfd: fix uninitialized output field for -EAGAIN race |
| - [sasha] YES This commit should be assigned a CVE because it fixes a security-relevant bug where user-facing interfaces were returning uninitialized memory to userspace. Specifically: 1. The commit fixes multiple userfaultfd ioctl operations that were leaving output fields uninitialized when returning -EAGAIN errors. 2. The code changes show that previously, when `atomic_read(&ctx->mmap_changing)` was true, the functions would return -EAGAIN immediately without properly initializing the output fields: - `user_uffdio_copy->copy` - `user_uffdio_zeropage->zeropage` - `user_uffdio_continue->mapped` - `user_uffdio_poison->updated` - `user_uffdio_move->move` 3. This could lead to information disclosure where kernel memory contents could be leaked to userspace through these uninitialized fields, as the commit message mentions: "the subnormal case that left copy.copy uninitialized". 4. The fixes add explicit `put_user(ret, &...)` calls to ensure these output fields are properly initialized with -EAGAIN before returning to userspace when the `mmap_changing` race condition occurs. 5. Like the similar CVE commits shown, this fix prevents potential information leakage through uninitialized memory, which is a security vulnerability that warrants a CVE. |
| a2620f8932fa KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception |
| - [sasha] **YES** This commit should be assigned a CVE based on the following analysis: ## Security Vulnerability Impact The commit fixes a security issue that involves: 1. **Use-after-free vulnerability**: As stated in the commit message, the issue is directly related to the fix from CVE-2022-3344 (commit ed129ec9057f) which addressed use-after-free scenarios in nested mode, but didn't handle SMM. 2. **Denial of Service potential**: The bug triggers a kernel WARN/crash when specific conditions are met ## Code Analysis The vulnerability occurs when: 1. A vCPU enters SMM mode via `KVM_SMI` ioctl 2. Invalid instructions cause triple fault leading to SHUTDOWN interception 3. KVM attempts to reset the vCPU, but the WARN triggers because the vCPU is still in SMM The fix adds: ```c #ifdef CONFIG_KVM_SMM if (is_smm(vcpu)) kvm_smm_changed(vcpu, false); #endif ``` This forces the vCPU out of SMM before reset, preventing the WARN/crash condition. ## CVE Assignment Criteria Met 1. **Security impact**: Use-after-free and DoS vulnerability 2. **Privilege requirement**: Requires local access with ability to create KVM VMs 3. **Reproducible**: Can be triggered via specific sequence of operations (shown in the commit message) 4. **Fix required**: Code changes show actual vulnerability being patched 5. **Related to existing CVE**: Extends previous fix for CVE-2022-3344 The commit clearly fixes a security vulnerability that meets the criteria for CVE assignment. |
| 52d349884738 iio: adc: ad7266: Fix potential timestamp alignment issue. |
| - [sasha] Looking at this commit carefully, I need to analyze whether this is a security vulnerability that requires a CVE. The commit message describes: 1. A timestamp alignment issue 2. The problem is on architectures where s64 is only 32-bit aligned 3. The fix changes `s64 timestamp` to `aligned_s64 timestamp` Looking at the code change: ```diff struct { __be16 sample[2]; - s64 timestamp; + aligned_s64 timestamp; } data __aligned(IIO_DMA_MINALIGN); ``` This is fixing a potential memory corruption issue. On architectures where s64 is only 32-bit aligned, there would be insufficient padding between the sample array and the timestamp field. This could lead to: 1. Buffer overflow when writing to the timestamp field 2. Memory corruption due to misaligned access 3. Potential kernel information disclosure The commit message explicitly mentions "insufficient padding would be left between the earlier elements and the timestamp," which is a clear indication of a memory layout issue that could lead to memory corruption. Looking at Similar Commit 1, which also was assigned a CVE, it similarly fixed a memory corruption issue by preventing array overflow. This current commit is fixing a similar class of bug - memory corruption due to incorrect structure layout. **YES** This should be assigned a CVE because it fixes a potential memory corruption vulnerability. The insufficient padding between structure members could lead to buffer overflows when accessing the timestamp field, particularly on architectures where s64 has weaker alignment requirements. Memory corruption bugs in kernel drivers are security-sensitive as they can potentially be exploited for privilege escalation or information disclosure. |
| 159ca7f18129 iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo |
| - [sasha] YES, this commit should be assigned a CVE. This commit fixes a denial of service vulnerability through infinite loop that leads to kernel soft lockup. Looking at the code change: ```c + if (!pattern_len) + pattern_len = ST_LSM6DSX_SAMPLE_SIZE; ``` The vulnerability arises when `pattern_len` is zero and the FIFO is not empty. In the existing code, the line `for (read_len = 0; read_len < fifo_len; read_len += pattern_len)` would create an infinite loop since `read_len` would never increment when `pattern_len` is zero. This is clearly a security issue because: 1. It causes a kernel soft lockup which is a denial of service condition 2. The lockup affects system availability and responsiveness 3. Similar lockup/deadlock fixes have received CVEs (see reference commits with CVE Status: YES that fix soft lockups and deadlocks) 4. The vulnerability exists in kernel driver code where infinite loops have system-wide impact The fix adds defensive programming to ensure pattern_len is never zero, preventing the lockup condition. |
| 8114ef86e205 iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo |
| - [sasha] YES This commit should be assigned a CVE because it fixes a security vulnerability that can cause system deadlock/denial of service. The code change adds a critical safety check to prevent an infinite loop condition: ```c + if (!pattern_len) + pattern_len = ST_LSM6DSX_TAGGED_SAMPLE_SIZE; ``` Without this check, if `pattern_len` is zero and the FIFO is not empty, the `for` loop becomes: ```c for (read_len = 0; read_len < fifo_len; read_len += pattern_len) ``` Since `pattern_len` is 0, `read_len` never increases, creating an infinite loop that can lock up the system. This is a classic denial-of-service vulnerability where invalid data or certain sensor states can trigger a system hang. The commit specifically states it "prevents st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero," confirming this is a security-relevant bug fix that addresses a potential system availability issue. |
| f063a28002e3 iio: light: opt3001: fix deadlock due to concurrent flag access |
| - [sasha] YES This commit should be assigned a CVE because it fixes a deadlock vulnerability that can impact system availability. The specific vulnerabilities are: 1. **Race Condition in Flag Access**: The code shows a thread safety issue where `opt->ok_to_ignore_lock` is read twice in the IRQ handler - once to decide whether to lock the mutex and once to decide whether to unlock it: ```c - if (!opt->ok_to_ignore_lock) + bool ok_to_ignore_lock = opt->ok_to_ignore_lock; + if (!ok_to_ignore_lock) mutex_lock(&opt->lock); ... - if (!opt->ok_to_ignore_lock) + if (!ok_to_ignore_lock) mutex_unlock(&opt->lock); ``` 2. **Deadlock Vulnerability**: The commit message explicitly states there are "subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage", which results in the mutex not being unlocked, causing a deadlock. 3. **Security Impact**: This deadlock can lead to denial of service as it affects system availability by causing an irrecoverable lock state in the driver. 4. **Similar CVE Patterns**: Looking at similar commits with "CVE Status: YES", we see other synchronization issues like: - Commit 1 (HID: i2c-hid): Fixes an infinite loop in interrupt handler causing lock-up - Commit 5 (rtl8192u): Fixes a deadlock in beacon stop function The fix stores the flag value in a local variable to ensure consistent behavior throughout the function execution, preventing the deadlock condition. |
| 35e4079bf1a2 drm/v3d: Add job to pending list if the reset was skipped |
| - [sasha] YES This commit fixes a memory leak vulnerability that occurs when GPU jobs are allowed to continue running after a timeout. When the GPU reset is skipped (because the GPU has made progress), the job is removed from the pending list but never gets properly freed, causing memory to leak over time. The code changes show: 1. The new function `v3d_sched_skip_reset()` is introduced to put jobs back on the pending list 2. This function is called in `v3d_cl_job_timedout()` and `v3d_csd_job_timedout()` when skipping reset 3. The fix ensures that jobs will be properly freed through the normal `free_job()` path when they complete This is a security-relevant bug fix that addresses a memory leak vulnerability that could lead to resource exhaustion. The commit explicitly references this as fixing a memory leak issue, similar to CVE-worthy issues in the kernel's graphics subsystem. |
| 3ca02e63edcc smb: client: Avoid race in open_cached_dir with lease breaks |
| - [sasha] Looking at this commit, I'll analyze the security implications: **YES** This commit should be assigned a CVE. Here's my analysis: 1. **Security Issue Identified**: The commit message explicitly states there's a "race" condition in `open_cached_dir` that leads to a **reference leak** when a valid cfid races with a lease break. This results in a **dentry reference leak**. 2. **Resource Leak Pattern**: Like the similar commits with CVE status, this fixes a resource leak caused by race conditions. The commit message states: ``` This leaks a dentry reference if the allocation occurs before the queued lease break work runs. ``` 3. **Race Condition with Security Impact**: The race condition occurs between: - Getting a cached directory entry from `find_or_create_cached_dir` - A lease break being processed - The leak happens when `open_cached_dir` doesn't consider the cfid valid but thinks it's newly-constructed 4. **Code Fix Pattern**: The fix involves extending lock holding: ```c // Before - lock is released early - spin_lock(&cfids->cfid_list_lock); // ... find_or_create_cached_dir operations - spin_unlock(&cfids->cfid_list_lock); // After - lock is held across both operations + spin_lock(&cfids->cfid_list_lock); cfid = find_or_create_cached_dir(cfids, path, lookup_only, tcon->max_cached_dirs); // ... validity check + spin_unlock(&cfids->cfid_list_lock); ``` 5. **Similar CVE Patterns**: All the reference commits with CVE status fix similar issues: - Memory/resource leaks due to race conditions in SMB client code - Race conditions between lease operations and cached directory handling - Reference counting issues that lead to resource exhaustion The security impact is denial of service through resource exhaustion (dentry reference leak), which aligns with the pattern of CVEs assigned to similar commits in this codebase. |
| cd9c05848905 xen: swiotlb: Use swiotlb bouncing if kmalloc allocation demands it |
| - [sasha] YES This commit fixes a security vulnerability that should be assigned a CVE. Here's the specific evidence: 1. **Data Corruption Vulnerability**: The commit message explicitly states "USB transfers ended up corrupted when there was more than one URB inflight at the same time." This is a data integrity issue that can have security implications. 2. **Missing Security Boundary Check**: The code change adds a critical security check `!dma_kmalloc_needs_bounce(dev, size, dir)` that was previously missing in the Xen swiotlb implementation. This check ensures that kmalloc allocations too small for DMA get properly bounced via swiotlb. 3. **Security Impact**: The vulnerability allows for DMA transfers to use improperly aligned memory, which can lead to data corruption when multiple concurrent operations occur. This could potentially be exploited to corrupt adjacent memory regions or leak sensitive data. 4. **Root Cause**: The issue stems from a missing implementation in the Xen swiotlb code after architectural changes were made to decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN. The failure to implement the bounce check for DMA-incompatible allocations creates a security gap. 5. **Real-world Impact**: The vulnerability manifests on systems without IOMMU protection (like iMX8QXP SoC), affecting real hardware configurations where DMA operations can directly access system memory without protection. Unlike the similar commits shown (which mostly dealt with general fixes, alignment adjustments, or build warnings), this commit addresses a specific security vulnerability where improper DMA handling leads to data corruption during concurrent operations. |
| 1f0304dfd9d2 xenbus: Use kref to track req lifetime |
| - [sasha] YES This commit should be assigned a CVE. The commit fixes a use-after-free vulnerability that can cause a NULL pointer dereference in the kernel. Key evidence from the commit: 1. **Actual crash report**: The commit message includes a kernel NULL pointer dereference bug report with a call trace: ``` BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: e030:__wake_up_common+0x4c/0x180 Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0 ``` 2. **Root cause**: The vulnerability is a race condition where `req` is freed by one thread while still being accessed by another thread: - "It seems like req may have woken up the xs_wait_for_reply(), which kfree()ed the req" - "When xenbus_thread resumes, it faults on the zero-ed data" 3. **Fix pattern**: The commit adds reference counting (kref) to properly manage the lifetime of `req` objects: ```c + struct kref kref; ``` and changes multiple kfree() calls to use kref_put(): ```c - kfree(req); + kref_put(&req->kref, xs_free_req); ``` 4. **Security impact**: This is a kernel vulnerability that can be triggered during normal xenbus operations, potentially leading to system crashes or other security implications in Xen virtualized environments. 5. **Stable kernel designation**: The commit includes "Cc: stable@vger.kernel.org", indicating this is considered a serious bug that needs to be backported to stable kernels. Similar to the referenced CVE commits that fix NULL pointer dereferences and race conditions in Xen components, this commit addresses a security-relevant memory management issue that can cause kernel crashes. |
| 157dbc4a321f KVM: arm64: Fix uninitialized memcache pointer in user_mem_abort() |
| - [sasha] Looking at both the commit message and code changes, I'll analyze whether this warrants a CVE assignment. **CVE Status: YES** This commit fixes a use-of-uninitialized-memory vulnerability in the KVM (Kernel-based Virtual Machine) hypervisor for ARM64. The bug could lead to unpredictable behavior when handling memory faults in guest VMs. **Explanation based on code analysis:** 1. **Security-Critical Component**: The fix is in the KVM MMU (Memory Management Unit) code, which handles memory mappings for virtual machines - a security-critical hypervisor component. 2. **Uninitialized Memory Bug**: The code changes show that the `memcache` pointer was not always initialized before being passed to `kvm_pgtable_stage2_map()`. This creates a code path where uninitialized memory could be used. 3. **The Fix**: The patch moves the initialization of `memcache` earlier in the function: ```c + if (!is_protected_kvm_enabled()) + memcache = &vcpu->arch.mmu_page_cache; + else + memcache = &vcpu->arch.pkvm_memcache; ``` This ensures `memcache` is always valid before any potential use. 4. **Security Impact**: Using uninitialized pointers in kernel/hypervisor code can lead to: - Information disclosure (if the uninitialized memory contains sensitive data) - Kernel crashes or denial of service - Potentially arbitrary code execution in worst cases 5. **Stable Backport**: The commit includes "Cc: stable@vger.kernel.org", indicating this is a serious bug that needs to be fixed in stable kernel releases. The vulnerability affects all code paths that "require a stage-2 allocation without transition via a permission fault or dirty logging," which represents a real attack surface for guest VMs trying to exploit the hypervisor. |
| da8bf5daa5e5 memblock: Accept allocated memory before use in memblock_double_array() |
| - [sasha] YES This commit should be assigned a CVE for the following reasons: 1. **Memory Safety Vulnerability**: The code changes fix a critical memory safety issue where unaccepted memory was being accessed before acceptance, resulting in a kernel crash. The stack trace shows a crash in `memcpy_orig` when attempting to use memory that hasn't been accepted yet: ``` RIP: 0010:memcpy_orig+0x68/0x130 ``` 2. **Security-Relevant Context**: This affects AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging) environments, which are security-critical virtualization technologies designed to protect guest VMs from the hypervisor. The vulnerability occurs in the boot process when the kernel tries to expand the memblock arrays. 3. **Fix Shows Security Impact**: The code change explicitly adds `accept_memory(addr, new_alloc_size)` before using the allocated memory: ```c if (addr) { /bin /bin.usr-is-merged /boot /dev /etc /home /init /lib /lib.usr-is-merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var The memory may not have been accepted, yet. bippy/ cve_classifier/ cve_utils/ dyad/ explain/ model/ target/ verhaal/ voting_results/ accept_memory(addr, new_alloc_size); new_array = __va(addr); } ``` 4. **System Availability Impact**: This vulnerability causes a kernel panic/crash during boot, which constitutes a denial of service condition in SEV-SNP protected environments. 5. **Similar to Commit 4**: Looking at the similar commits, Commit 4 with CVE status YES also fixed an issue where unaccepted memory caused crashes and was assigned a CVE. This commit follows the same pattern - fixing crashes related to accessing unaccepted memory before acceptance. The vulnerability represents a security issue because it breaks the security model of SEV-SNP where memory must be explicitly accepted before use, and the crash prevents the system from booting properly in secure virtualization environments. |
| a6aeb739974e module: ensure that kobject_put() is safe for module type kobjects |
| - [sasha] YES This commit should be assigned a CVE because it fixes a kernel vulnerability involving uninitialized memory access. Specifically: 1. **Uninitialized pointer dereference**: The code change shows that `complete(mk->kobj_completion)` was being called without checking if the pointer was initialized, which could lead to kernel crashes or undefined behavior when accessing uninitialized memory. 2. **Kernel context vulnerability**: This occurs in the kernel module subsystem (`kernel/params.c`), where memory safety issues can have system-wide impact. 3. **Exploitable path**: The issue occurs in error handling paths during kobject creation, which could potentially be triggered by attackers through specific module operations. 4. **Similar CVE precedent**: All the similar commits that received CVEs were also fixing memory safety issues (use-after-free, uninitialized access) in kernel space, particularly in kobject handling code. The fix adds a simple but critical NULL check: `if (mk->kobj_completion)` before calling `complete()`, preventing access to uninitialized memory that could lead to system instability or potential exploitation. |
| 31d4cd4eb2f8 ocfs2: fix panic in failed foilio allocation |
| - [sasha] Looking at this commit carefully, I need to analyze both the nature of the fix and its security implications. YES This commit should be assigned a CVE for the following reasons: 1. **Security Impact**: The code change fixes a panic (kernel crash) that occurs during failed folio allocation. Kernel panics are considered security vulnerabilities because they can lead to denial of service. 2. **Root Cause**: The vulnerability exists because the error handling code expects either valid folio pointers or NULL in the array, but the code was storing an error value (-ENOMEM) instead. When the cleanup code tries to process this invalid pointer value, it causes a panic: ```c ret = PTR_ERR(folios[numfolios]); mlog_errno(ret); folios[numfolios] = NULL; // This was missing before the fix ``` 3. **Exploitability**: This could be triggered when memory allocation fails, which could potentially be induced under memory pressure conditions. The commit message explicitly states "Finding the -ENOMEM will result in a panic." 4. **Similar Pattern**: Looking at the similar commits provided, I see that commit 4 with a similar allocation race panic fix was given CVE status: ``` Similar Commit 4 [CVE Status: YES]: Subject: mm/gup: fix memfd_pin_folios alloc race panic ``` The fix is straightforward - ensuring that failed allocations result in NULL entries rather than error pointers - but the vulnerability itself could lead to system crashes, making it worthy of CVE assignment. |
| 364618c89d4c usb: typec: ucsi: displayport: Fix deadlock |
| - [sasha] Let me analyze this commit for security implications: YES This commit should be assigned a CVE. Here's why: 1. **Deadlock Fix**: The commit explicitly fixes a deadlock scenario in the USB Type-C UCSI displayport driver. Deadlocks can lead to denial of service, which is a security issue. 2. **Security Impact**: The commit message clearly states: ``` This resolves a deadlock scenario where ucsi_displayport_remove_partner holds con->mutex waiting for dp_altmode_work to complete while dp_altmode_work attempts to acquire it. ``` 3. **Comparison with Similar CVE-Assigned Commits**: Looking at the similar commits provided: - Commit 4 (CVE: YES) - Fixed a NULL pointer access issue - Commit 5 (CVE: YES) - Also fixed a NULL pointer access issue - Both these commits, like this one, fix resource access/synchronization issues 4. **Code Changes Show Critical Fix**: The introduction of `ucsi_con_mutex_lock()` and `ucsi_con_mutex_unlock()` functions with proper connection checks prevents the deadlock: ```c +bool ucsi_con_mutex_lock(struct ucsi_connector *con) +{ + bool mutex_locked = false; + bool connected = true; + + while (connected && !mutex_locked) { + mutex_locked = mutex_trylock(&con->lock) != 0; + connected = UCSI_CONSTAT(con, CONNECTED); + if (connected && !mutex_locked) + msleep(20); + } ``` 5. **Stable Kernel Marking**: The commit is marked with `Cc: stable <stable@kernel.org>`, indicating it's considered important enough for backporting to stable kernels, which is common for security fixes. A deadlock in kernel space can freeze the system or specific subsystems, effectively creating a denial of service condition. This is a security vulnerability that warrants CVE assignment. |
| 312d79669e71 usb: typec: ucsi: displayport: Fix NULL pointer access |
| - [sasha] YES This commit should be assigned a CVE for the following reasons: 1. **Null Pointer Dereference**: The commit explicitly fixes a "NULL pointer access" vulnerability, which is a security issue that can cause crashes, denial of service, or potentially be exploited for privilege escalation. 2. **Code Pattern Matches CVE-Assigned Commits**: The fix adds `cancel_work_sync(&dp->work)` before releasing resources, which is exactly the same pattern seen in similar commits that were assigned CVEs: - Similar Commit 1 (CVE Status: YES): Moved `destroy_workqueue(con->wq)` before `ucsi_unregister_partner()` - Similar Commit 2 (CVE Status: YES): Also moved workqueue destruction before partner unregistration - Similar Commit 4 (CVE Status: YES): Added mutex protection to prevent NULL pointer access 3. **Race Condition Fix**: The fix addresses a race condition where pending tasks in the workqueue could still be accessing the `dp` structure after it's been freed: ```c + cancel_work_sync(&dp->work); dp->data.conf = 0; dp->data.status = 0; dp->initialized = false; ``` 4. **Security Impact**: Without this fix, concurrent calls to `ucsi_displayport_work()` (which accesses `dp`) and `ucsi_displayport_remove_partner()` (which cleans up `dp`) could lead to use-after-free conditions. 5. **Stable Kernel Tag**: The presence of `Cc: stable <stable@kernel.org>` indicates this fix is considered important enough to backport to stable kernels, which is typically done for security issues. The fix ensures that all pending work is completed before cleaning up resources, preventing NULL pointer dereferences that could lead to kernel crashes or other security issues. |
| 75680b7cd461 accel/ivpu: Correct mutex unlock order in job submission |
| - [sasha] Let me analyze this commit based on the provided information. **YES** This commit fixes a security vulnerability related to mutex unlock ordering that could lead to race conditions. The specific issue: 1. **Race Condition Fix**: The commit message explicitly states the fix is to "avoid potential race conditions" by correcting the mutex unlock order. Race conditions are classic security vulnerabilities that can lead to unpredictable behavior, data corruption, or privilege escalation. 2. **Critical Path**: The bug is in the job submission path (`ivpu_job_submit()` function), which is a critical operation that affects the execution of jobs on the Intel VPU accelerator. 3. **Locking Order Violation**: The code change shows that `vdev->submitted_jobs_lock` was being unlocked before `file_priv->lock`, which violates proper lock ordering. This can create a time window where concurrent operations could access shared resources in an inconsistent state. 4. **Similarity to Other CVEs**: Looking at the similar commits provided: - Similar Commit 2 (CVE Status: YES) fixed a deadlock in context_xa - Similar Commit 4 (CVE Status: YES) fixed a deadlock in ivpu_ms_cleanup() - Similar Commit 3 and 5 (CVE Status: YES) both involved pm_runtime state issues All of these CVE-assigned commits involved synchronization issues (deadlocks, race conditions) similar to this commit. 5. **Security Impact**: Incorrect mutex ordering can lead to: - Race conditions that could corrupt data structures - Potential denial of service through deadlocks - Unpredictable behavior that could be exploited The commit clearly fixes a concurrency vulnerability that could have security implications, similar to other mutex/locking fixes in the same codebase that have been assigned CVEs. |
| b53e523261bf io_uring: always arm linked timeouts prior to issue |
| - [sasha] I need to analyze this commit to determine if it requires a CVE assignment. Looking at the commit message: - It describes a race condition where linked timeouts aren't fully armed before request execution - References stable@vger.kernel.org for backporting - Reports a potential for memory corruption and unstable behavior - Has a clear security impact with timing issues Analyzing the code changes: - Consolidates linked timeout handling into `__io_issue_sqe()` instead of having it spread across various issue points - Removes `io_arm_ltimeout()` calls from multiple locations - Ensures timeouts are armed before the main request is executed - The key change is moving the linked timeout preparation and queueing to happen atomically with the operation issue Comparing with similar commits: - Similar to "io_uring: fix ltout double free on completion race" (CVE Status: YES) which also addressed race conditions with linked timeouts - Similar to "io_uring: fix link timeout refs" (CVE Status: YES) which also fixed reference counting issues with linked timeouts - The pattern of fixing race conditions in linked timeout handling has precedent for CVE assignment The security implications: - Race conditions can lead to use-after-free vulnerabilities - Timing issues with linked timeouts could cause memory corruption - The fact it's marked for stable backporting indicates it's a real vulnerability **YES** This commit should be assigned a CVE. It fixes a race condition in linked timeout handling that could lead to memory corruption and unstable behavior. The consolidated handling pattern ensures linked timeouts are properly armed before issuing operations, preventing the race condition where callbacks could trigger before timeout setup is complete. This is similar to other CVE-assigned commits that fixed race conditions in io_uring's linked timeout handling (e.g., the ltimeout double free and link timeout refs fixes). |
| 0dfefc2ea2f2 arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs |
| - [sasha] YES This commit should be assigned a CVE because it is fixing a security vulnerability - specifically, it's addressing a speculative execution vulnerability (Spectre-BHB) in BPF programs. Key evidence from the code: 1. **Security fix nature**: The commit adds mitigation for the Branch History Buffer (BHB) attack variant of Spectre. The commit message explicitly states: "A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next." 2. **Attack scenario**: The patch protects against malicious BPF programs that could manipulate branch prediction history to perform speculative attacks. 3. **Concrete mitigation code added**: - New function `build_bhb_mitigation()` that implements the mitigation - Uses hardware-specific methods like `AARCH64_INSN_HINT_CLEARBHB` - Falls back to software loops and firmware workarounds (ARM_SMCCC_ARCH_WORKAROUND_3) - Only applied for classic cBPF programs loaded by seccomp 4. **Similar to other CVE-worthy commits**: Other Spectre-related fixes have been assigned CVEs, and this commit addresses a similar security boundary issue where untrusted BPF code could potentially influence speculative execution to leak sensitive information. 5. **Scope is security-critical**: This affects BPF programs loaded by seccomp, which is a security sandboxing mechanism, making the security impact significant. The commit adds real security mitigation code to prevent potential information disclosure through speculative execution attacks, which clearly qualifies as a vulnerability fix deserving a CVE assignment. |
| d4e89d212d40 x86/bpf: Call branch history clearing sequence on exit |
| - [sasha] YES This commit should be assigned a CVE because it fixes a security vulnerability that allows unprivileged users to perform intra-mode Branch Target Injection (BTI) attacks through classic BPF programs. Key evidence from the code changes: 1. **Security check for unprivileged users**: The code specifically adds protection only for unprivileged users: ```c if (bpf_prog_was_classic(bpf_prog) && !capable(CAP_SYS_ADMIN)) { ``` 2. **Spectre/BTI mitigation**: The commit adds a branch history buffer clearing sequence specifically to prevent malicious branch history manipulation: ```c if (emit_spectre_bhb_barrier(&prog, ip, bpf_prog)) return -EINVAL; ``` 3. **Attack vector**: The commit message explicitly states that "Attackers can use unprivileged cBPF to craft branch history in kernel mode that can influence the target of indirect branches." 4. **Feature-specific mitigation**: The code uses hardware mitigation when available (`X86_FEATURE_CLEAR_BHB_LOOP`) and calls `clear_bhb_loop()` to clear branch history. The commit demonstrates a clear security vulnerability where unprivileged code could influence kernel branch predictions, which is a serious security issue warranting CVE assignment. |
| 9f725eec8fc0 x86/bpf: Add IBHF call at end of classic BPF |
| - [sasha] YES, this commit should be assigned a CVE. This commit fixes a security vulnerability where classic BPF programs run by unprivileged users can bypass kernel protections against Branch History Injection (BHI) attacks. The vulnerability allows unprivileged code to craft branch history within the kernel that can influence indirect branch targets, potentially leading to speculative execution attacks. Key evidence from the code changes: 1. The commit adds a security mitigation (IBHF instruction) to the BPF JIT compiler: ```c + /bin /bin.usr-is-merged /boot /dev /etc /home /init /lib /lib.usr-is-merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var Insert IBHF instruction bippy/ cve_classifier/ cve_utils/ dyad/ explain/ model/ target/ verhaal/ voting_results/ + if ((cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_LOOP) && + cpu_feature_enabled(X86_FEATURE_HYPERVISOR)) || + (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_HW) && + IS_ENABLED(CONFIG_X86_64))) { + /bin /bin.usr-is-merged /boot /dev /etc /home /init /lib /lib.usr-is-merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var + Cargo.lock Cargo.toml bippy cve_classifier cve_utils dyad explain log.txt model target verhaal voting_results Add an Indirect Branch History Fence (IBHF). IBHF acts as a + Cargo.lock Cargo.toml bippy cve_classifier cve_utils dyad explain log.txt model target verhaal voting_results fence preventing branch history from before the fence from + Cargo.lock Cargo.toml bippy cve_classifier cve_utils dyad explain log.txt model target verhaal voting_results affecting indirect branches after the fence. This is + Cargo.lock Cargo.toml bippy cve_classifier cve_utils dyad explain log.txt model target verhaal voting_results specifically used in cBPF jitted code to prevent Intra-mode + Cargo.lock Cargo.toml bippy cve_classifier cve_utils dyad explain log.txt model target verhaal voting_results BHI attacks. + bippy/ cve_classifier/ cve_utils/ dyad/ explain/ model/ target/ verhaal/ voting_results/ + EMIT5(0xF3, 0x48, 0x0F, 0x1E, 0xF8); /bin /bin.usr-is-merged /boot /dev /etc /home /init /lib /lib.usr-is-merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var ibhf bippy/ cve_classifier/ cve_utils/ dyad/ explain/ model/ target/ verhaal/ voting_results/ + } ``` 2. The vulnerability allows bypassing existing BHI protections, as stated in the commit message: "BHI_DIS_S provides user-kernel isolation of branch history, but cBPF can be used to bypass this protection by crafting branch history in kernel mode." 3. The fix is specifically targeting a security vulnerability that allows unprivileged users to influence kernel behavior through speculative execution attacks via BPF programs. This is similar to other BHI-related vulnerabilities that have been assigned CVEs, and it represents a specific attack vector that bypasses existing security mitigations. |
| 159013a7ca18 x86/its: Enumerate Indirect Target Selection (ITS) bug |
| - [sasha] YES This commit should be assigned a CVE because: 1. The commit message explicitly states this is a "bug in some pre-Alderlake Intel CPUs" that can allow "indirect branches in the first half of a cache line get predicted to a target of a branch located in the second half of the cache line." 2. The code changes show this is a security vulnerability being added to the kernel's bug tracking: - Add `X86_BUG_ITS` to the CPU bug enumeration in `arch/x86/include/asm/cpufeatures.h` - Add `ARCH_CAP_ITS_NO` capability bit to indicate CPUs not susceptible to this vulnerability - Add affected CPU models to the vulnerability blacklist in `cpu_vuln_blacklist[]` - Implement detection logic in `vulnerable_to_its()` that checks for affected CPUs 3. The vulnerable CPU list includes many Intel processor families (Skylake, Kabylake, Icelake, Cometlake, etc.) with specific stepping ranges, showing this affects a wide range of hardware. 4. KVM support is added to expose this vulnerability status to guests, indicating this is a real security issue that needs to be tracked across virtualization boundaries. 5. The pattern follows other CPU security vulnerabilities like BHI, RFDS, and Spectre, which all have CVEs assigned. The code structure and detection mechanism are identical to these other CPU security bugs. The indirect branch prediction issue described can potentially be exploited to leak sensitive information across security boundaries, making this a legitimate security vulnerability that warrants CVE assignment. |
