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: 4EXPL: 0CVE-2022-48939 – bpf: Add schedule points in batch ops
https://notcve.org/view.php?id=CVE-2022-48939
In the Linux kernel, the following vulnerability has been resolved: bpf: Add schedule points in batch ops syzbot reported various soft lockups caused by bpf batch operations. INFO: task kworker/1:1:27 blocked for more than 140 seconds. INFO: task hung in rcu_barrier Nothing prevents batch ops to process huge amount of data, we need to add schedule points in them. Note that maybe_wait_bpf_programs(map) calls from generic_map_delete_batch() can be factorized by moving the call after the loop. This will be done later in -next tree once we get this fix merged, unless there is strong opinion doing this optimization sooner. • https://git.kernel.org/stable/c/aa2e93b8e58e18442edfb2427446732415bc215e https://git.kernel.org/stable/c/7ef94bfb08fb9e73defafbd5ddef6b5a0e2ee12b https://git.kernel.org/stable/c/8628f489b749a4f9767991631921dbe3fbcdc784 https://git.kernel.org/stable/c/7e8099967d0e3ff9d1ae043e80b27fbe46c08417 https://git.kernel.org/stable/c/75134f16e7dd0007aa474b281935c5f42e79f2c8 •