CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2024-40911 – wifi: cfg80211: Lock wiphy in cfg80211_get_station
https://notcve.org/view.php?id=CVE-2024-40911
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Lock wiphy in cfg80211_get_station Wiphy should be locked before calling rdev_get_station() (see lockdep assert in ieee80211_get_station()). This fixes the following kernel NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr : sta_set_sinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 ieee80211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x1ec/0x414 worker_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814) This happens because STA has time to disconnect and reconnect before batadv_v_elp_throughput_metric_update() delayed work gets scheduled. In this situation, ath10k_sta_state() can be in the middle of resetting arsta data when the work queue get chance to be scheduled and ends up accessing it. Locking wiphy prevents that. • https://git.kernel.org/stable/c/7406353d43c8e2faf478721e87aeb6f2f9685de0 https://git.kernel.org/stable/c/dfd84ce41663be9ca3f69bd657c45f49b69344d9 https://git.kernel.org/stable/c/6d540b0317901535275020bd4ac44fac6439ca76 https://git.kernel.org/stable/c/0ccc63958d8373e15a69f4f8069f3e78f7f3898a https://git.kernel.org/stable/c/43e1eefb0b2094e2281150d87d09e8bc872b9fba https://git.kernel.org/stable/c/642f89daa34567d02f312d03e41523a894906dae https://access.redhat.com/security/cve/CVE-2024-40911 https://bugzilla.redhat.com/show_bug.cgi?id=2297495 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-40910 – ax25: Fix refcount imbalance on inbound connections
https://notcve.org/view.php?id=CVE-2024-40910
In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: <TASK> ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? • https://git.kernel.org/stable/c/9fd75b66b8f68498454d685dc4ba13192ae069b0 https://git.kernel.org/stable/c/c44a453ffe16eb08acdc6129ac4fa0192dbc0456 https://git.kernel.org/stable/c/de55a1338e6a48ff1e41ea8db1432496fbe2a62b https://git.kernel.org/stable/c/9e1e088a57c23251f1cfe9601bbd90ade2ea73b9 https://git.kernel.org/stable/c/b20a5ab0f5fb175750c6bafd4cf12daccf00c738 https://git.kernel.org/stable/c/452ae92b99062d2f6a34324eaf705a3b7eac9f8b https://git.kernel.org/stable/c/534156dd4ed768e30a43de0036f45dca7c54818f https://git.kernel.org/stable/c/f4df9d6c8d4e4c818252b0419c2165d66 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40909 – bpf: Fix a potential use-after-free in bpf_link_free()
https://notcve.org/view.php?id=CVE-2024-40909
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a potential use-after-free in bpf_link_free() After commit 1a80dbcb2dba, bpf_link can be freed by link->ops->dealloc_deferred, but the code still tests and uses link->ops->dealloc afterward, which leads to a use-after-free as reported by syzbot. Actually, one of them should be sufficient, so just call one of them instead of both. Also add a WARN_ON() in case of any problematic implementation. • https://git.kernel.org/stable/c/876941f533e7b47fc69977fc4551c02f2d18af97 https://git.kernel.org/stable/c/1a80dbcb2dbaf6e4c216e62e30fa7d3daa8001ce https://git.kernel.org/stable/c/5d8d447777564b35f67000e7838e7ccb64d525c8 https://git.kernel.org/stable/c/91cff53136daeff50816b0baeafd38a6976f6209 https://git.kernel.org/stable/c/fa97b8fed9896f1e89cb657513e483a152d4c382 https://git.kernel.org/stable/c/2884dc7d08d98a89d8d65121524bb7533183a63a •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-40908 – bpf: Set run context for rawtp test_run callback
https://notcve.org/view.php?id=CVE-2024-40908
In the Linux kernel, the following vulnerability has been resolved: bpf: Set run context for rawtp test_run callback syzbot reported crash when rawtp program executed through the test_run interface calls bpf_get_attach_cookie helper or any other helper that touches task->bpf_ctx pointer. Setting the run context (task->bpf_ctx pointer) for test_run callback. • https://git.kernel.org/stable/c/7adfc6c9b315e174cf8743b21b7b691c8766791b https://git.kernel.org/stable/c/789bd77c9342aa6125003871ae5c6034d0f6f9d2 https://git.kernel.org/stable/c/3708b6c2546c9eb34aead8a34a17e8ae69004e4d https://git.kernel.org/stable/c/d387805d4b4a46ee01e3dae133c81b6d80195e5b https://git.kernel.org/stable/c/ae0ba0ab7475a129ef7d449966edf677367efeb4 https://git.kernel.org/stable/c/d0d1df8ba18abc57f28fb3bc053b2bf319367f2c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-40906 – net/mlx5: Always stop health timer during driver removal
https://notcve.org/view.php?id=CVE-2024-40906
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always stop health timer during driver removal Currently, if teardown_hca fails to execute during driver removal, mlx5 does not stop the health timer. Afterwards, mlx5 continue with driver teardown. This may lead to a UAF bug, which results in page fault Oops[1], since the health timer invokes after resources were freed. Hence, stop the health monitor even if teardown_hca fails. [1] mlx5_core 0000:18:00.0: E-Switch: Unload vfs: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5_core 0000:18:00.0: E-Switch: cleanup mlx5_core 0000:18:00.0: wait_func:1155:(pid 1967079): TEARDOWN_HCA(0x103) timeout. Will cause a leak of a command resource mlx5_core 0000:18:00.0: mlx5_function_close:1288:(pid 1967079): tear_down_hca failed, skip cleanup BUG: unable to handle page fault for address: ffffa26487064230 PGD 100c00067 P4D 100c00067 PUD 100e5a067 PMD 105ed7067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE ------- --- 6.7.0-68.fc38.x86_64 #1 Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 RIP: 0010:ioread32be+0x34/0x60 RSP: 0018:ffffa26480003e58 EFLAGS: 00010292 RAX: ffffa26487064200 RBX: ffff9042d08161a0 RCX: ffff904c108222c0 RDX: 000000010bbf1b80 RSI: ffffffffc055ddb0 RDI: ffffa26487064230 RBP: ffff9042d08161a0 R08: 0000000000000022 R09: ffff904c108222e8 R10: 0000000000000004 R11: 0000000000000441 R12: ffffffffc055ddb0 R13: ffffa26487064200 R14: ffffa26480003f00 R15: ffff904c108222c0 FS: 0000000000000000(0000) GS:ffff904c10800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa26487064230 CR3: 00000002c4420006 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? __die+0x23/0x70 ? • https://git.kernel.org/stable/c/9b98d395b85dd042fe83fb696b1ac02e6c93a520 https://git.kernel.org/stable/c/e7d4485d47839f4d1284592ae242c4e65b2810a9 https://git.kernel.org/stable/c/6ccada6ffb42e0ac75e3db06d41baf5a7f483f8a https://git.kernel.org/stable/c/e6777ae0bf6fd5bc626bb051c8c93e3c8198a3f8 https://git.kernel.org/stable/c/c8b3f38d2dae0397944814d691a419c451f9906f •