CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-43889 – padata: Fix possible divide-by-0 panic in padata_mt_helper()
https://notcve.org/view.php?id=CVE-2024-43889
In the Linux kernel, the following vulnerability has been resolved: padata: Fix possible divide-by-0 panic in padata_mt_helper() We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time. [ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1 [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: events_unbound padata_mt_helper [ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0 : [ 10.017963] Call Trace: [ 10.017968] <TASK> [ 10.018004] ? padata_mt_helper+0x39/0xb0 [ 10.018084] process_one_work+0x174/0x330 [ 10.018093] worker_thread+0x266/0x3a0 [ 10.018111] kthread+0xcf/0x100 [ 10.018124] ret_from_fork+0x31/0x50 [ 10.018138] ret_from_fork_asm+0x1a/0x30 [ 10.018147] </TASK> Looking at the padata_mt_helper() function, the only way a divide-by-0 panic can happen is when ps->chunk_size is 0. The way that chunk_size is initialized in padata_do_multithreaded(), chunk_size can be 0 when the min_chunk in the passed-in padata_mt_job structure is 0. Fix this divide-by-0 panic by making sure that chunk_size will be at least 1 no matter what the input parameters are. A denial of service vulnerability exists in the Linux kernel. A possible divide-by-0 is in the padata_mt_helper() function when the ps->chunk_size is 0. • https://git.kernel.org/stable/c/004ed42638f4428e70ead59d170f3d17ff761a0f https://git.kernel.org/stable/c/ab8b397d5997d8c37610252528edc54bebf9f6d3 https://git.kernel.org/stable/c/8f5ffd2af7274853ff91d6cd62541191d9fbd10d https://git.kernel.org/stable/c/a29cfcb848c31f22b4de6a531c3e1d68c9bfe09f https://git.kernel.org/stable/c/924f788c906dccaca30acab86c7124371e1d6f2c https://git.kernel.org/stable/c/da0ffe84fcc1627a7dff82c80b823b94236af905 https://git.kernel.org/stable/c/6d45e1c948a8b7ed6ceddb14319af69424db730c https://access.redhat.com/security/cve/CVE-2024-43889 • CWE-369: Divide By Zero •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43886 – drm/amd/display: Add null check in resource_log_pipe_topology_update
https://notcve.org/view.php?id=CVE-2024-43886
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check in resource_log_pipe_topology_update [WHY] When switching from "Extend" to "Second Display Only" we sometimes call resource_get_otg_master_for_stream on a stream for the eDP, which is disconnected. This leads to a null pointer dereference. [HOW] Added a null check in dc_resource.c/resource_log_pipe_topology_update. • https://git.kernel.org/stable/c/c36e922a36bdf69765c340a0857ca74092003bee https://git.kernel.org/stable/c/899d92fd26fe780aad711322aa671f68058207a6 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43884 – Bluetooth: MGMT: Add error handling to pair_device()
https://notcve.org/view.php?id=CVE-2024-43884
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Add error handling to pair_device() hci_conn_params_add() never checks for a NULL value and could lead to a NULL pointer dereference causing a crash. Fixed by adding error handling in the function. • https://git.kernel.org/stable/c/5157b8a503fa834e8569c7fed06981e3d3d53db0 https://git.kernel.org/stable/c/11b4b0e63f2621b33b2e107407a7d67a65994ca1 https://git.kernel.org/stable/c/90e1ff1c15e5a8f3023ca8266e3a85869ed03ee9 https://git.kernel.org/stable/c/9df9783bd85610d3d6e126a1aca221531f6f6dcb https://git.kernel.org/stable/c/951d6cb5eaac5130d076c728f2a6db420621afdb https://git.kernel.org/stable/c/5da2884292329bc9be32a7778e0e119f06abe503 https://git.kernel.org/stable/c/064dd929c76532359d2905d90a7c12348043cfd4 https://git.kernel.org/stable/c/ee0799103b1ae4bcfd80dc11a15df085f •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43883 – usb: vhci-hcd: Do not drop references before new references are gained
https://notcve.org/view.php?id=CVE-2024-43883
In the Linux kernel, the following vulnerability has been resolved: usb: vhci-hcd: Do not drop references before new references are gained At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver. • https://git.kernel.org/stable/c/5a3c473b28ae1c1f7c4dc129e30cb19ae6e96f89 https://git.kernel.org/stable/c/9c3746ce8d8fcb3a2405644fc0eec7fc5312de80 https://git.kernel.org/stable/c/4dacdb9720aaab10b6be121eae55820174d97174 https://git.kernel.org/stable/c/e8c1e606dab8c56cf074b43b98d0805de7322ba2 https://git.kernel.org/stable/c/585e6bc7d0a9bf73a8be3d3fb34e86b90cc61a14 https://git.kernel.org/stable/c/128e82e41cf7d74a562726c1587d9d2ede1a0a37 https://git.kernel.org/stable/c/c3d0857b7fc2c49f68f89128a5440176089a8f54 https://git.kernel.org/stable/c/afdcfd3d6fcdeca2735ca8d994c5f2d24 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48941 – ice: fix concurrent reset and removal of VFs
https://notcve.org/view.php?id=CVE-2022-48941
In the Linux kernel, the following vulnerability has been resolved: ice: fix concurrent reset and removal of VFs Commit c503e63200c6 ("ice: Stop processing VF messages during teardown") introduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is intended to prevent some issues with concurrently handling messages from VFs while tearing down the VFs. This change was motivated by crashes caused while tearing down and bringing up VFs in rapid succession. It turns out that the fix actually introduces issues with the VF driver caused because the PF no longer responds to any messages sent by the VF during its .remove routine. This results in the VF potentially removing its DMA memory before the PF has shut down the device queues. Additionally, the fix doesn't actually resolve concurrency issues within the ice driver. It is possible for a VF to initiate a reset just prior to the ice driver removing VFs. This can result in the remove task concurrently operating while the VF is being reset. This results in similar memory corruption and panics purportedly fixed by that commit. Fix this concurrency at its root by protecting both the reset and removal flows using the existing VF cfg_lock. • https://git.kernel.org/stable/c/c503e63200c679e362afca7aca9d3dc63a0f45ed https://git.kernel.org/stable/c/8a08142433624fd1088bc8c13639408cf4e1707c https://git.kernel.org/stable/c/05ae1f0fe9c6c5ead08b306e665763a352d20716 https://git.kernel.org/stable/c/3c805fce07c9dbc47d8a9129c7c5458025951957 https://git.kernel.org/stable/c/2a3e61de89bab6696aa28b70030eb119968c5586 https://git.kernel.org/stable/c/fadead80fe4c033b5e514fcbadd20b55c4494112 •