Breno Leitao

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: A softlockup issue in the ` read vmcore` function has been resolved. This issue occurred in memory-constrained environments, such as the kdump image, and could interfere with memory freeing by RCU, causing the crashdump to get stuck. The second loop in ` read vmcore` has more opportunities for natural sleep points, but adding a `cond resched()` to this loop should help eliminate the softlockups. Recommendations: To resolve this issue, apply the patch that adds a `cond resched()` to the second loop in ` read vmcore`. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: A vulnerability in the Linux kernel has been resolved, which previously caused the kernel to panic when interrupt allocation failed under certain conditions during runtime. The issue was observed when using failslab, resulting in a kernel panic with an error message indicating the failure to add an irq-pin. The problem was caused by a leftover from historic IO/APIC code that panicked during early boot when interrupt allocation failed. The fix involves removing the panic wrapper around the ` add pin to irq node()` function and making the `mp irqdomain alloc()` function aware of the failure condition to handle it gracefully. Recommendations: For Linux kernel versions prior to 6.6.58, update to version 6.6.58 or later to resolve the issue. As a temporary workaround, consider disabling the `mp irqdomain alloc()` function or restricting its use until a patch is available. However, this is not a recommended long-term solution, and updating to a fixed version is the preferred resolution.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: A vulnerability in the Linux kernel has been fixed, related to the TPM event log table, a Linux-specific construct where data produced by the GetEventLog() boot service is cached in memory and passed on to the OS using an EFI configuration table. The use of EFI LOADER DATA results in the region being left unreserved in the E820 memory map, which can lead to corruption and potentially crash the kernel. The fix involves using EFI ACPI RECLAIM MEMORY instead, which is always treated as reserved by the E820 conversion logic. Recommendations: For Linux kernel versions prior to 6.6.58, update to version 6.6.58 or later to resolve the issue. As a temporary workaround, consider disabling the use of EFI LOADER DATA for the TPM event log table until a patch is available. Restrict access to the TPM event log table to minimize the risk of exploitation. Avoid using the `GetEventLog()` boot service in the affected kernel versions until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: A vulnerability has been resolved in the Linux kernel, specifically in the blk iocost component, where out of bound shifts were caught by UBSAN in the `ioc forgive debts()` function. The issue occurred due to shift exponents being too large for 64-bit type 'u64'. The actual impact of this issue was not identified, but a fix was proposed to prevent undefined behavior by precalculating the exponent before using it in shift operations. Recommendations: For Linux kernel versions prior to 6.6.58, update to version 6.6.58 or later to resolve the issue. As a temporary workaround, consider restricting the use of the `blk iocost` component until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A memory out-of-bounds issue has been resolved in the Linux kernel, specifically in the `bnxt en` module. The issue arises from a recent commit that modified the code in ` bnxt reserve rings()` to set the default RSS indirection table to default only when the number of RX rings is changing. This change causes a regression on older firmware that does not require RX ring reservations. The comparison `if (old rx rings != bp->hw resc.resv rx rings)` in ` bnxt reserve rings()` may be false even when the RX rings are changing, leading to ` bnxt reserve rings()` skipping the setting of the default RSS indirection table. This may later cause `bnxt fill hw rss tbl()` to use an out-of-range index. The fix involves moving `bnxt check rss tbl no rmgr()` up in `bnxt need reserve rings()` to be called unconditionally when using older firmware. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the prevention of Spectre v1 gadget construction in the sys rtas() function. The 'nargs' and 'nret' locals come directly from a user-supplied buffer and are used as indexes into a small stack-based array and as inputs to copy to user() after they are subject to bounds checks. To address this, array index nospec() is used after the bounds checks to clamp these values for speculative execution. The Smatch tool warns of a potential spectre issue with 'args.args'. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to a potential out-of-bounds access when using `test bit()` on a single word. The `test bit()` and `set bit()` functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump, indicating a slab-out-of-bounds error in ` scsih add device.constprop.0`. The allocation should be at least the size of `sizeof(unsigned long)` to prevent `set bit()` and `test bit()` from overwriting unallocated memory. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** A data race vulnerability has been resolved in the Linux kernel's KVM module. The issue occurred in the `kvm vcpu on spin()` function, where a data race on `last boosted vcpu` could potentially allow KVM to attempt to get a vCPU using an out-of-bounds index. This could happen if the compiler tears the stores, and the write is split into multiple 8-bit stores, paired with a 32-bit load on a VM with 257 vCPUs. The vulnerability was detected by KCSAN. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel versions prior to 6.9-rc7 **Description** A data-race condition has been identified in the af unix component of the Linux kernel. This issue occurs because the write function `unix release sock()` atomically writes to `sk->sk shutdown` using `WRITE ONCE`, but the reader side, `unix stream sendmsg()`, does not read it atomically. This can cause a KCSAN splat to occur, indicating a data-race in `unix release sock` and `unix stream sendmsg`. The issue is related to the `unix stream sendmsg()` function not being protected by `unix state lock()`, unlike other reads. **Recommendations** To resolve this issue, update the Linux kernel to version 6.9-rc7 or later. As a temporary workaround, consider disabling the `unix stream sendmsg()` function until a patch is available. Restrict access to the vulnerable `af unix` module to minimize the risk of exploitation. Avoid using the `sk->sk shutdown` variable in the affected API endpoints until the issue is resolved. At the moment, there is no information about additional mitigation measures.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to a race condition in the `netpoll owner active()` function, which can lead to a data-race in `net rx action` and `netpoll send skb`. This happens because `netpoll owner active()` needs to check if the current CPU is the owner of the lock, touching `napi->poll owner` non-atomically. The `->poll owner` field contains the current CPU holding the lock. To fix this, an atomic read should be used to check if the poll owner is the current CPU. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** The issue is related to the sched/eevdf component in the Linux kernel, where the function `reweight eevdf()` computes the `vlag` without considering the limit placed upon `vlag` as `update entity lag()` does. This can lead to a scaling multiplication overflow, causing the new `vruntime` to be incorrect, which in turn leads to `entity eligible()` returning falsely negative. As a result, `pick eevdf()` may return NULL, causing a NULL-deref. The problem is rare but fatal when it occurs. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Linux kernel (affected versions not specified) **Description** There is a bug in the Linux kernel when setting the RSS options in virtio net that can break the whole machine, getting the kernel into an infinite loop. This issue can be reproduced by running the command `# ethtool -X eth0 hfunc toeplitz` in any QEMU virtual machine with virtionet. The problem occurs because the `virtnet commit rss command()` function populates 4 entries for the rss scatter-gather, and since the command above does not have a key, the last scatter-gather entry will be zeroed. This buffer is then passed to qemu, which is not happy with a buffer with zero length, resulting in an error. The kernel is waiting for the response to come back, but qemu has bailed out, causing the kernel to loop forever. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.