CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42321 – net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE
https://notcve.org/view.php?id=CVE-2024-42321
In the Linux kernel, the following vulnerability has been resolved: net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE The following splat is easy to reproduce upstream as well as in -stable kernels. Florian Westphal provided the following commit: d1dab4f71d37 ("net: add and use __skb_get_hash_symmetric_net") but this complementary fix has been also suggested by Willem de Bruijn and it can be easily backported to -stable kernel which consists in using DEBUG_NET_WARN_ON_ONCE instead to silence the following splat given __skb_get_hash() is used by the nftables tracing infrastructure to to identify packets in traces. [69133.561393] ------------[ cut here ]------------ [69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/ [...] [69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379 [69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0 [69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8 [69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246 [69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19 [69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418 [69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000 [69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400 [69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28 [69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0 [69133.562040] Call Trace: [69133.562044] <IRQ> [69133.562049] ? __warn+0x9f/0x1a0 [ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860 [...] [ 1211.841496] ? bpf_flow_dissect+0x160/0x160 [ 1211.841753] __skb_get_hash+0x97/0x280 [ 1211.841765] ? • https://git.kernel.org/stable/c/9b52e3f267a6835efd50ed9002d530666d16a411 https://git.kernel.org/stable/c/eb03d9826aa646577342a952d658d4598381c035 https://git.kernel.org/stable/c/4afbac11f2f629d1e62817c4e210bdfaa7521107 https://git.kernel.org/stable/c/c5d21aabf1b31a79f228508af33aee83456bc1b0 https://git.kernel.org/stable/c/120f1c857a73e52132e473dee89b340440cb692b •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42319 – mailbox: mtk-cmdq: Move devm_mbox_controller_register() after devm_pm_runtime_enable()
https://notcve.org/view.php?id=CVE-2024-42319
In the Linux kernel, the following vulnerability has been resolved: mailbox: mtk-cmdq: Move devm_mbox_controller_register() after devm_pm_runtime_enable() When mtk-cmdq unbinds, a WARN_ON message with condition pm_runtime_get_sync() < 0 occurs. According to the call tracei below: cmdq_mbox_shutdown mbox_free_channel mbox_controller_unregister __devm_mbox_controller_unregister ... The root cause can be deduced to be calling pm_runtime_get_sync() after calling pm_runtime_disable() as observed below: 1. CMDQ driver uses devm_mbox_controller_register() in cmdq_probe() to bind the cmdq device to the mbox_controller, so devm_mbox_controller_unregister() will automatically unregister the device bound to the mailbox controller when the device-managed resource is removed. That means devm_mbox_controller_unregister() and cmdq_mbox_shoutdown() will be called after cmdq_remove(). 2. CMDQ driver also uses devm_pm_runtime_enable() in cmdq_probe() after devm_mbox_controller_register(), so that devm_pm_runtime_disable() will be called after cmdq_remove(), but before devm_mbox_controller_unregister(). To fix this problem, cmdq_probe() needs to move devm_mbox_controller_register() after devm_pm_runtime_enable() to make devm_pm_runtime_disable() be called after devm_mbox_controller_unregister(). • https://git.kernel.org/stable/c/623a6143a845bd485b00ba684f0ccef11835edab https://git.kernel.org/stable/c/1403991a40b94438a2acc749bf05c117abdb34f9 https://git.kernel.org/stable/c/d00df6700ad10974a7e20646956f4ff22cdbe0ec https://git.kernel.org/stable/c/11fa625b45faf0649118b9deaf2d31c86ac41911 https://git.kernel.org/stable/c/a8bd68e4329f9a0ad1b878733e0f80be6a971649 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42315 – exfat: fix potential deadlock on __exfat_get_dentry_set
https://notcve.org/view.php?id=CVE-2024-42315
In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential deadlock on __exfat_get_dentry_set When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set. The problem is that the bh-array is allocated with GFP_KERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur. CPU0 CPU1 ---- ---- kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... evict exfat_evict_inode lock(&sbi->s_lock) To fix this, let's allocate bh-array with GFP_NOFS. • https://git.kernel.org/stable/c/bd3bdb9e0d656f760b11d0c638d35d7f7068144d https://git.kernel.org/stable/c/92dcd7d6c6068bf4fd35a6f64d606e27d634807e https://git.kernel.org/stable/c/a3ff29a95fde16906304455aa8c0bd84eb770258 https://git.kernel.org/stable/c/632fb232b6bbf8277edcbe9ecd4b4d98ecb122eb https://git.kernel.org/stable/c/c052f775ee6ccacd3c97e4cf41a2a657e63d4259 https://git.kernel.org/stable/c/a7ac198f8dba791e3144c4da48a5a9b95773ee4b https://git.kernel.org/stable/c/1d1970493c289e3f44b9ec847ed26a5dbdf56a62 https://git.kernel.org/stable/c/89fc548767a2155231128cb98726d6d2e •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42313 – media: venus: fix use after free in vdec_close
https://notcve.org/view.php?id=CVE-2024-42313
In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free in vdec_close There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst. Fix it by cancelling the work in vdec_close. • https://git.kernel.org/stable/c/af2c3834c8ca7cc65d15592ac671933df8848115 https://git.kernel.org/stable/c/ad8cf035baf29467158e0550c7a42b7bb43d1db6 https://git.kernel.org/stable/c/72aff311194c8ceda934f24fd6f250b8827d7567 https://git.kernel.org/stable/c/4c9d235630d35db762b85a4149bbb0be9d504c36 https://git.kernel.org/stable/c/f8e9a63b982a8345470c225679af4ba86e4a7282 https://git.kernel.org/stable/c/da55685247f409bf7f976cc66ba2104df75d8dad https://git.kernel.org/stable/c/66fa52edd32cdbb675f0803b3c4da10ea19b6635 https://git.kernel.org/stable/c/6a96041659e834dc0b172dda4b2df512d •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-42312 – sysctl: always initialize i_uid/i_gid
https://notcve.org/view.php?id=CVE-2024-42312
In the Linux kernel, the following vulnerability has been resolved: sysctl: always initialize i_uid/i_gid Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them. Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed. • https://git.kernel.org/stable/c/5ec27ec735ba0477d48c80561cc5e856f0c5dfaf https://git.kernel.org/stable/c/e83234d7ef237931148b4b17834dadf57eb46c12 https://git.kernel.org/stable/c/2cbf2af144f0cd08a3361c6299b2e6086b7d21d9 https://git.kernel.org/stable/c/2c7b50c7b1d036f71acd9a917a8cb0f9b6e43dab https://git.kernel.org/stable/c/7eb45a94c279dd5af4cafaa738ae93737517eef4 https://git.kernel.org/stable/c/14cc90952cef94bfa89a6b4a2f55fd9a70f50a16 https://git.kernel.org/stable/c/b2591c89a6e2858796111138c38fcb6851aa1955 https://git.kernel.org/stable/c/34a86adea1f2b3c3f9d864c8cce09dca6 •