CVE-2024-36000 – mm/hugetlb: fix missing hugetlb_lock for resv uncharge
https://notcve.org/view.php?id=CVE-2024-36000
20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix missing hugetlb_lock for resv uncharge There is a recent report on UFFDIO_COPY over hugetlb: https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/ 350: lockdep_assert_held(&hugetlb_lock); Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the ... • https://git.kernel.org/stable/c/79aa925bf239c234be8586780e482872dc4690dd •
CVE-2024-35999 – smb3: missing lock when picking channel
https://notcve.org/view.php?id=CVE-2024-35999
20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: smb3: missing lock when picking channel Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index. Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)") En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb3: falta el bloqueo al seleccionar el canal. Coverity detectó un lugar donde deberíamos haber mantenido el bloqueo del canal al acceder al índice del canal ... • https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729 •
CVE-2024-35998 – smb3: fix lock ordering potential deadlock in cifs_sync_mid_result
https://notcve.org/view.php?id=CVE-2024-35998
20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: smb3: fix lock ordering potential deadlock in cifs_sync_mid_result Coverity spotted that the cifs_sync_mid_result function could deadlock "Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock" Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)") En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb3: corrige el posible i... • https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66 •
CVE-2024-35997 – HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
https://notcve.org/view.php?id=CVE-2024-35997
20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that. More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the... • https://git.kernel.org/stable/c/4a200c3b9a40242652b5734630bdd0bcf3aca75f • CWE-400: Uncontrolled Resource Consumption CWE-667: Improper Locking •
CVE-2024-35996 – cpu: Re-enable CPU mitigations by default for !X86 architectures
https://notcve.org/view.php?id=CVE-2024-35996
20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: cpu: Re-enable CPU mitigations by default for !X86 architectures Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to turn mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta missed that "cpu_mitigations" is completely generic, whereas SPECULATION_MITIGATIONS is x86-specific. Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it... • https://git.kernel.org/stable/c/70688450dddaf91e12fd4fc625da3297025932c9 •
CVE-2024-35995 – ACPI: CPPC: Use access_width over bit_width for system memory accesses
https://notcve.org/view.php?id=CVE-2024-35995
20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Use access_width over bit_width for system memory accesses To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform. SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009... • https://git.kernel.org/stable/c/4949affd5288b867cdf115f5b08d6166b2027f87 •
CVE-2024-35994 – firmware: qcom: uefisecapp: Fix memory related IO errors and crashes
https://notcve.org/view.php?id=CVE-2024-35994
20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: uefisecapp: Fix memory related IO errors and crashes It turns out that while the QSEECOM APP_SEND command has specific fields for request and response buffers, uefisecapp expects them both to be in a single memory region. Failure to adhere to this has (so far) resulted in either no response being written to the response buffer (causing an EIO to be emitted down the line), the SCM call to fail with EINVAL (i.e., directly from... • https://git.kernel.org/stable/c/759e7a2b62eb3ef3c93ffeb5cca788a09627d7d9 •
CVE-2024-35993 – mm: turn folio_test_hugetlb into a PageType
https://notcve.org/view.php?id=CVE-2024-35993
20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: mm: turn folio_test_hugetlb into a PageType The current folio_test_hugetlb() can be fooled by a concurrent folio split into returning true for a folio which has never belonged to hugetlbfs. This can't happen if the caller holds a refcount on it, but we have a few places (memory-failure, compaction, procfs) which do not and should not take a speculative reference. Since hugetlb pages do not use individual page mapcounts (they are always full... • https://git.kernel.org/stable/c/9c5ccf2db04b8d7c3df363fdd4856c2b79ab2c6a •
CVE-2024-35992 – phy: marvell: a3700-comphy: Fix out of bounds read
https://notcve.org/view.php?id=CVE-2024-35992
20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: phy: marvell: a3700-comphy: Fix out of bounds read There is an out of bounds read access of 'gbe_phy_init_fix[fix_idx].addr' every iteration after 'fix_idx' reaches 'ARRAY_SIZE(gbe_phy_init_fix)'. Make sure 'gbe_phy_init[addr]' is used when all elements of 'gbe_phy_init_fix' array are handled. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: marvell: a3... • https://git.kernel.org/stable/c/934337080c6c59b75db76b180b509f218640ad48 • CWE-125: Out-of-bounds Read •
CVE-2024-35991 – dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
https://notcve.org/view.php?id=CVE-2024-35991
20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue drain_workqueue() cannot be called safely in a spinlocked context due to possible task rescheduling. In the multi-task scenario, calling queue_work() while drain_workqueue() will lead to a Call Trace as pushing a work on a draining workqueue is not permitted in spinlocked context. Call Trace: <TASK> ? __warn+0x7d/0x140 ? __queue_work+0x2b2/0x440 ? • https://git.kernel.org/stable/c/c40bd7d9737bdcfb02d42765bc6c59b338151123 •