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: 5EXPL: 0CVE-2024-42320 – s390/dasd: fix error checks in dasd_copy_pair_store()
https://notcve.org/view.php?id=CVE-2024-42320
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error checks in dasd_copy_pair_store() dasd_add_busid() can return an error via ERR_PTR() if an allocation fails. However, two callsites in dasd_copy_pair_store() do not check the result, potentially resulting in a NULL pointer dereference. Fix this by checking the result with IS_ERR() and returning the error up the stack. • https://git.kernel.org/stable/c/a91ff09d39f9b6545254839ac91f1ff7bd21d39e https://git.kernel.org/stable/c/932600a295cc299d470ca7f5d6491bd0dfc99ea7 https://git.kernel.org/stable/c/cc8b7284d5076722e0b8062373b68d8e47c3bace https://git.kernel.org/stable/c/e511167e65d332d07b3c7a3d5a741ee9c19a8c27 https://git.kernel.org/stable/c/68d4c3722290ad300c295fb3435e835d200d5cb2 https://git.kernel.org/stable/c/8e64d2356cbc800b4cd0e3e614797f76bcf0cdb8 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 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/11fa625b45faf0649118b9deaf2d31c86ac41911 https://git.kernel.org/stable/c/a8bd68e4329f9a0ad1b878733e0f80be6a971649 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42318 – landlock: Don't lose track of restrictions on cred_transfer
https://notcve.org/view.php?id=CVE-2024-42318
In the Linux kernel, the following vulnerability has been resolved: landlock: Don't lose track of restrictions on cred_transfer When a process' cred struct is replaced, this _almost_ always invokes the cred_prepare LSM hook; but in one special case (when KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the cred_transfer LSM hook is used instead. Landlock only implements the cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes all information on Landlock restrictions to be lost. This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself. Fix it by adding a cred_transfer hook that does the same thing as the existing cred_prepare hook. (Implemented by having hook_cred_prepare() call hook_cred_transfer() so that the two functions are less likely to accidentally diverge in the future.) Linux has an issue where landlock can be disabled thanks to a missing cred_transfer hook. • https://git.kernel.org/stable/c/385975dca53eb41031d0cbd1de318eb1bc5d6bb9 https://git.kernel.org/stable/c/916c648323fa53b89eedb34a0988ddaf01406117 https://git.kernel.org/stable/c/0d74fd54db0bd0c0c224bef0da8fc95ea9c9f36c https://git.kernel.org/stable/c/16896914bace82d7811c62f3b6d5320132384f49 https://git.kernel.org/stable/c/b14cc2cf313bd29056fadbc8ecd7f957cf5791ff https://git.kernel.org/stable/c/39705a6c29f8a2b93cf5b99528a55366c50014d1 https://lore.kernel.org/all/20240817.shahka3Ee1iy@digikod.net https://www.openwall.com/lists/oss-security/2024/08/17& •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42317 – mm/huge_memory: avoid PMD-size page cache if needed
https://notcve.org/view.php?id=CVE-2024-42317
In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: avoid PMD-size page cache if needed xarray can't support arbitrary page cache size. the largest and supported page cache size is defined as MAX_PAGECACHE_ORDER by commit 099d90642a71 ("mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray"). However, it's possible to have 512MB page cache in the huge memory's collapsing path on ARM64 system whose base page size is 64KB. 512MB page cache is breaking the limitation and a warning is raised when the xarray entry is split as shown in the following example. [root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize KernelPageSize: 64 kB [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c : int main(int argc, char **argv) { const char *filename = TEST_XFS_FILENAME; int fd = 0; void *buf = (void *)-1, *p; int pgsize = getpagesize(); int ret = 0; if (pgsize != 0x10000) { fprintf(stdout, "System with 64KB base page size is required!\n"); return -EPERM; } system("echo 0 > /sys/devices/virtual/bdi/253:0/read_ahead_kb"); system("echo 1 > /proc/sys/vm/drop_caches"); /* Open the xfs file */ fd = open(filename, O_RDONLY); assert(fd > 0); /* Create VMA */ buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ, MAP_SHARED, fd, 0); assert(buf ! • https://git.kernel.org/stable/c/6b24ca4a1a8d4ee3221d6d44ddbb99f542e4bda3 https://git.kernel.org/stable/c/e60f62f75c99740a28e2bf7e6044086033012a16 https://git.kernel.org/stable/c/d659b715e94ac039803d7601505d3473393fc0be •