CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46858 – mptcp: pm: Fix uaf in __timer_delete_sync
https://notcve.org/view.php?id=CVE-2024-46858
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: Fix uaf in __timer_delete_sync There are two paths to access mptcp_pm_del_add_timer, result in a race condition: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entry) In remove_anno_list_by_saddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1). Keeping a reference to add_timer inside the lock, and calling sk_stop_timer_sync() with this reference, instead of "entry->add_timer". Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf. • https://git.kernel.org/stable/c/00cfd77b9063dcdf3628a7087faba60de85a9cc8 https://git.kernel.org/stable/c/0e7814b028cd50b3ff79659d23dfa9da6a1e75e1 https://git.kernel.org/stable/c/3554482f4691571fc4b5490c17ae26896e62171c https://git.kernel.org/stable/c/67409b358500c71632116356a0b065f112d7b707 https://git.kernel.org/stable/c/6452b162549c7f9ef54655d3fb9977b9192e6e5b https://git.kernel.org/stable/c/12134a652b0a10064844ea235173e70246eba6dc https://git.kernel.org/stable/c/b4cd80b0338945a94972ac3ed54f8338d2da2076 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46857 – net/mlx5: Fix bridge mode operations when there are no VFs
https://notcve.org/view.php?id=CVE-2024-46857
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix bridge mode operations when there are no VFs Currently, trying to set the bridge mode attribute when numvfs=0 leads to a crash: bridge link set dev eth2 hwmode vepa [ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] [ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core] [...] [ 168.976037] Call Trace: [ 168.976188] <TASK> [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core] [ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core] [ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0 [ 168.979714] rtnetlink_rcv_msg+0x159/0x400 [ 168.980451] netlink_rcv_skb+0x54/0x100 [ 168.980675] netlink_unicast+0x241/0x360 [ 168.980918] netlink_sendmsg+0x1f6/0x430 [ 168.981162] ____sys_sendmsg+0x3bb/0x3f0 [ 168.982155] ___sys_sendmsg+0x88/0xd0 [ 168.985036] __sys_sendmsg+0x59/0xa0 [ 168.985477] do_syscall_64+0x79/0x150 [ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 168.987773] RIP: 0033:0x7f8f7950f917 (esw->fdb_table.legacy.vepa_fdb is null) The bridge mode is only relevant when there are multiple functions per port. Therefore, prevent setting and getting this setting when there are no VFs. Note that after this change, there are no settings to change on the PF interface using `bridge link` when there are no VFs, so the interface no longer appears in the `bridge link` output. • https://git.kernel.org/stable/c/4b89251de024fb85329e4cbd8fbea551ae6c665c https://git.kernel.org/stable/c/52c4beb79e095e0631b5cac46ed48a2aefe51985 https://git.kernel.org/stable/c/65feee671e37f3b6eda0b6af28f204b5bcf7fa50 https://git.kernel.org/stable/c/505ae01f75f839b54329164bbfecf24cc1361b31 https://git.kernel.org/stable/c/b1d305abef4640af1b4f1b4774d513cd81b10cfc •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46855 – netfilter: nft_socket: fix sk refcount leaks
https://notcve.org/view.php?id=CVE-2024-46855
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_socket: fix sk refcount leaks We must put 'sk' reference before returning. • https://git.kernel.org/stable/c/039b1f4f24ecc8493b6bb9d70b4b78750d1b35c2 https://git.kernel.org/stable/c/6934809432d23e9e0081f82d882b8fc765deeb4a https://git.kernel.org/stable/c/f63432cd1bb224f61216e4a4726ff29ddffbed98 https://git.kernel.org/stable/c/ddc7c423c4a5386bf865474c694b48178efd311a https://git.kernel.org/stable/c/33c2258bf8cb17fba9e58b111d4c4f4cf43a4896 https://git.kernel.org/stable/c/83e6fb59040e8964888afcaa5612cc1243736715 https://git.kernel.org/stable/c/1f68e097e20d3c695281a9c6433acc37be47fe11 https://git.kernel.org/stable/c/8b26ff7af8c32cb4148b3e147c52f9e4c •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46854 – net: dpaa: Pad packets to ETH_ZLEN
https://notcve.org/view.php?id=CVE-2024-46854
In the Linux kernel, the following vulnerability has been resolved: net: dpaa: Pad packets to ETH_ZLEN When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running $ ping -s 11 destination • https://git.kernel.org/stable/c/9ad1a37493338cacf04e2c93acf44d151a7adda8 https://git.kernel.org/stable/c/cd5b9d657ecd44ad5f254c3fea3a6ab1cf0e2ef7 https://git.kernel.org/stable/c/dc43a096cfe65b5c32168313846c5cd135d08f1d https://git.kernel.org/stable/c/1f31f51bfc8214a6deaac2920e6342cb9d019133 https://git.kernel.org/stable/c/38f5db5587c0ee53546b28c50ba128253181ac83 https://git.kernel.org/stable/c/f43190e33224c49e1c7ebbc25923ff400d87ec00 https://git.kernel.org/stable/c/34fcac26216ce17886af3eb392355b459367af1a https://git.kernel.org/stable/c/ce8eabc912fe9b9a62be1a5c6af5ad219 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46853 – spi: nxp-fspi: fix the KASAN report out-of-bounds bug
https://notcve.org/view.php?id=CVE-2024-46853
In the Linux kernel, the following vulnerability has been resolved: spi: nxp-fspi: fix the KASAN report out-of-bounds bug Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO. To reproduce the issue, write 3 bytes data to NOR chip. dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated--- • https://git.kernel.org/stable/c/a5356aef6a907c2e2aed0caaa2b88b6021394471 https://git.kernel.org/stable/c/aa05db44db5f409f6d91c27b5737efb49fb45d9f https://git.kernel.org/stable/c/609260542cf86b459c57618b8cdec8020394b7ad https://git.kernel.org/stable/c/491f9646f7ac31af5fca71be1a3e5eb8aa7663ad https://git.kernel.org/stable/c/09af8b0ba70072be831f3ec459f4063d570f9e24 https://git.kernel.org/stable/c/af9ca9ca3e44f48b2a191e100d452fbf850c3d87 https://git.kernel.org/stable/c/d1a1dfcec77c57b1181da93d11a3db1bc4eefa97 https://git.kernel.org/stable/c/2a8787c1cdc7be24fdd8953ecd1a8743a •