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: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2024-40905 – ipv6: fix possible race in __fib6_drop_pcpu_from()
https://notcve.org/view.php?id=CVE-2024-40905
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible race in __fib6_drop_pcpu_from() syzbot found a race in __fib6_drop_pcpu_from() [1] If compiler reads more than once (*ppcpu_rt), second read could read NULL, if another cpu clears the value in rt6_get_pcpu_route(). Add a READ_ONCE() to prevent this race. Also add rcu_read_lock()/rcu_read_unlock() because we rely on RCU protection while dereferencing pcpu_rt. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 • https://git.kernel.org/stable/c/d52d3997f843ffefaa8d8462790ffcaca6c74192 https://git.kernel.org/stable/c/c90af1cced2f669a7b2304584be4ada495eaa0e5 https://git.kernel.org/stable/c/c693698787660c97950bc1f93a8dd19d8307153d https://git.kernel.org/stable/c/a0bc020592b54a8f3fa2b7f244b6e39e526c2e12 https://git.kernel.org/stable/c/2498960dac9b6fc49b6d1574f7cd1a4872744adf https://git.kernel.org/stable/c/7e796c3fefa8b17b30e7252886ae8cffacd2b9ef https://git.kernel.org/stable/c/09e5a5a80e205922151136069e440477d6816914 https://git.kernel.org/stable/c/b01e1c030770ff3b4fe37fc7cc6bca03f • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40904 – USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages
https://notcve.org/view.php?id=CVE-2024-40904
In the Linux kernel, the following vulnerability has been resolved: USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages The syzbot fuzzer found that the interrupt-URB completion callback in the cdc-wdm driver was taking too long, and the driver's immediate resubmission of interrupt URBs with -EPROTO status combined with the dummy-hcd emulation to cause a CPU lockup: cdc_wdm 1-1:1.0: nonzero urb status received: -71 cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625] CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idle Modules linked in: irq event stamp: 73096 hardirqs last enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline] hardirqs last enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Testing showed that the problem did not occur if the two error messages -- the first two lines above -- were removed; apparently adding material to the kernel log takes a surprisingly large amount of time. In any case, the best approach for preventing these lockups and to avoid spamming the log with thousands of error messages per second is to ratelimit the two dev_err() calls. Therefore we replace them with dev_err_ratelimited(). • https://git.kernel.org/stable/c/9908a32e94de2141463e104c9924279ed3509447 https://git.kernel.org/stable/c/217d1f44fff560b3995a685a60aa66e55a7f0f56 https://git.kernel.org/stable/c/05b2cd6d33f700597e6f081b53c668a226a96d28 https://git.kernel.org/stable/c/c0747d76eb05542b5d49f67069b64ef5ff732c6c https://git.kernel.org/stable/c/53250b54c92fe087fd4b0c48f85529efe1ebd879 https://git.kernel.org/stable/c/02a4c0499fc3a02e992b4c69a9809912af372d94 https://git.kernel.org/stable/c/72a3fe36cf9f0d030865e571f45a40f9c1e07e8a https://git.kernel.org/stable/c/82075aff7ffccb1e72b0ac8aa349e4736 • CWE-667: Improper Locking •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40902 – jfs: xattr: fix buffer overflow for invalid xattr
https://notcve.org/view.php?id=CVE-2024-40902
In the Linux kernel, the following vulnerability has been resolved: jfs: xattr: fix buffer overflow for invalid xattr When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jfs: xattr: corrige el desbordamiento del búfer para xattr no válido Cuando un tamaño de xattr no es el esperado, se imprime en el registro del kernel en formato hexadecimal como una forma de depuración. Pero cuando el tamaño de xattr es mayor que el tamaño esperado, imprimirlo puede provocar un acceso desde el final del búfer. Solucione todo esto restringiendo adecuadamente el tamaño del volcado hexadecimal de depuración en el registro del kernel. • https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0 https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7 https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123 https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69 https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •