CVSS: 6.1EPSS: 0%CPEs: 5EXPL: 0CVE-2024-40927 – xhci: Handle TD clearing for multiple streams case
https://notcve.org/view.php?id=CVE-2024-40927
In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again. [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. • https://git.kernel.org/stable/c/e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 https://git.kernel.org/stable/c/26460c1afa311524f588e288a4941432f0de6228 https://git.kernel.org/stable/c/633f72cb6124ecda97b641fbc119340bd88d51a9 https://git.kernel.org/stable/c/949be4ec5835e0ccb3e2a8ab0e46179cb5512518 https://git.kernel.org/stable/c/61593dc413c3655e4328a351555235bc3089486a https://git.kernel.org/stable/c/5ceac4402f5d975e5a01c806438eb4e554771577 https://access.redhat.com/security/cve/CVE-2024-40927 https://bugzilla.redhat.com/show_bug.cgi?id=2297511 • CWE-820: Missing Synchronization •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40924 – drm/i915/dpt: Make DPT object unshrinkable
https://notcve.org/view.php?id=CVE-2024-40924
In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Make DPT object unshrinkable In some scenarios, the DPT object gets shrunk but the actual framebuffer did not and thus its still there on the DPT's vm->bound_list. Then it tries to rewrite the PTEs via a stale CPU mapping. This causes panic. [vsyrjala: Add TODO comment] (cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c) • https://git.kernel.org/stable/c/0dc987b699ce4266450d407d6d79d41eab88c5d0 https://git.kernel.org/stable/c/327280149066f0e5f2e50356b5823f76dabfe86e https://git.kernel.org/stable/c/7a9883be3b98673333eec65c4a21cc18e60292eb https://git.kernel.org/stable/c/a2552020fb714ff357182c3c179abfac2289f84d https://git.kernel.org/stable/c/43e2b37e2ab660c3565d4cff27922bc70e79c3f1 https://access.redhat.com/security/cve/CVE-2024-40924 https://bugzilla.redhat.com/show_bug.cgi?id=2297508 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40921 – net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state
https://notcve.org/view.php?id=CVE-2024-40921
In the Linux kernel, the following vulnerability has been resolved: net: bridge: mst: pass vlan group directly to br_mst_vlan_set_state Pass the already obtained vlan group pointer to br_mst_vlan_set_state() instead of dereferencing it again. Each caller has already correctly dereferenced it for their context. This change is required for the following suspicious RCU dereference fix. No functional changes intended. • https://git.kernel.org/stable/c/8ca9a750fc711911ef616ceb627d07357b04545e https://git.kernel.org/stable/c/4488617e5e995a09abe4d81add5fb165674edb59 https://git.kernel.org/stable/c/e43dd2b1ec746e105b7db5f9ad6ef14685a615a4 https://git.kernel.org/stable/c/a2b01e65d9ba8af2bb086d3b7288ca53a07249ac https://git.kernel.org/stable/c/09f4337c27f5bdeb8646a6db91488cc2f7d537ff https://git.kernel.org/stable/c/a6cc9e9a651b9861efa068c164ee62dfba68c6ca https://git.kernel.org/stable/c/d2dc02775fc0c4eacaee833a0637e5958884a8e5 https://git.kernel.org/stable/c/36c92936e868601fa1f43da6758cf5580 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40920 – net: bridge: mst: fix suspicious rcu usage in br_mst_set_state
https://notcve.org/view.php?id=CVE-2024-40920
In the Linux kernel, the following vulnerability has been resolved: net: bridge: mst: fix suspicious rcu usage in br_mst_set_state I converted br_mst_set_state to RCU to avoid a vlan use-after-free but forgot to change the vlan group dereference helper. Switch to vlan group RCU deref helper to fix the suspicious rcu usage warning. • https://git.kernel.org/stable/c/8ca9a750fc711911ef616ceb627d07357b04545e https://git.kernel.org/stable/c/4488617e5e995a09abe4d81add5fb165674edb59 https://git.kernel.org/stable/c/e43dd2b1ec746e105b7db5f9ad6ef14685a615a4 https://git.kernel.org/stable/c/a2b01e65d9ba8af2bb086d3b7288ca53a07249ac https://git.kernel.org/stable/c/caaa2129784a04dcade0ea92c12e6ff90bbd23d8 https://git.kernel.org/stable/c/7caefa2771722e65496d85b62e1dc4442b7d1345 https://git.kernel.org/stable/c/406bfc04b01ee47e4c626f77ecc7d9f85135b166 https://git.kernel.org/stable/c/546ceb1dfdac866648ec959cbc71d9525 •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40919 – bnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send()
https://notcve.org/view.php?id=CVE-2024-40919
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send() In case of token is released due to token->state == BNXT_HWRM_DEFERRED, released token (set to NULL) is used in log messages. This issue is expected to be prevented by HWRM_ERR_CODE_PF_UNAVAILABLE error code. But this error code is returned by recent firmware. So some firmware may not return it. This may lead to NULL pointer dereference. Adjust this issue by adding token pointer check. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/8fa4219dba8e621aa1e78dfa7eeab10f55acb3c0 https://git.kernel.org/stable/c/cde177fa235cd36f981012504a6376315bac03c9 https://git.kernel.org/stable/c/ca6660c956242623b4cfe9be2a1abc67907c44bf https://git.kernel.org/stable/c/8b65eaeae88d4e9f999e806e196dd887b90bfed9 https://git.kernel.org/stable/c/a9b9741854a9fe9df948af49ca5514e0ed0429df https://access.redhat.com/security/cve/CVE-2024-40919 https://bugzilla.redhat.com/show_bug.cgi?id=2297503 • CWE-476: NULL Pointer Dereference •