CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50033 – slip: make slhc_remember() more robust against malicious packets
https://notcve.org/view.php?id=CVE-2024-50033
In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 • https://git.kernel.org/stable/c/b5451d783ade99308dfccdf5ca284ed07affa4ff https://git.kernel.org/stable/c/36b054324d18e51cf466134e13b6fbe3c91f52af https://git.kernel.org/stable/c/5e336384cc9b608e0551f99c3d87316ca3b0e51a https://git.kernel.org/stable/c/ff5e0f895315706e4ca5a19df15be6866cee4f5d https://git.kernel.org/stable/c/8bb79eb1db85a10865f0d4dd15b013def3f2d246 https://git.kernel.org/stable/c/29e8d96d44f51cf89a62dd042be35d052833b95c https://git.kernel.org/stable/c/7d3fce8cbe3a70a1c7c06c9b53696be5d5d8dd5c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50028 – thermal: core: Reference count the zone in thermal_zone_get_by_id()
https://notcve.org/view.php?id=CVE-2024-50028
In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure. • https://git.kernel.org/stable/c/1ce50e7d408ef2bdc8ca021363fd46d1b8bfad00 https://git.kernel.org/stable/c/c95538b286efc6109c987e97a051bc7844ede802 https://git.kernel.org/stable/c/a42a5839f400e929c489bb1b58f54596c4535167 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50024 – net: Fix an unsafe loop on the list
https://notcve.org/view.php?id=CVE-2024-50024
In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list. • https://git.kernel.org/stable/c/b8273570f802a7658827dcb077b0b517ba75a289 https://git.kernel.org/stable/c/68ad5da6ca630a276f0a5c924179e57724d00013 https://git.kernel.org/stable/c/1cdec792b2450105b1314c5123a9a0452cb2c2f0 https://git.kernel.org/stable/c/5f03a7f601f33cda1f710611625235dc86fd8a9e https://git.kernel.org/stable/c/3be342e0332a7c83eb26fbb22bf156fdca467a5d https://git.kernel.org/stable/c/49f9b726bf2bf3dd2caf0d27cadf4bc1ccf7a7dd https://git.kernel.org/stable/c/1dae9f1187189bc09ff6d25ca97ead711f7e26f9 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50018 – net: napi: Prevent overflow of napi_defer_hard_irqs
https://notcve.org/view.php?id=CVE-2024-50018
In the Linux kernel, the following vulnerability has been resolved: net: napi: Prevent overflow of napi_defer_hard_irqs In commit 6f8b12d661d0 ("net: napi: add hard irqs deferral feature") napi_defer_irqs was added to net_device and napi_defer_irqs_count was added to napi_struct, both as type int. This value never goes below zero, so there is not reason for it to be a signed int. Change the type for both from int to u32, and add an overflow check to sysfs to limit the value to S32_MAX. The limit of S32_MAX was chosen because the practical limit before this patch was S32_MAX (anything larger was an overflow) and thus there are no behavioral changes introduced. If the extra bit is needed in the future, the limit can be raised. Before this patch: $ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs' $ cat /sys/class/net/eth4/napi_defer_hard_irqs -2147483647 After this patch: $ sudo bash -c 'echo 2147483649 > /sys/class/net/eth4/napi_defer_hard_irqs' bash: line 0: echo: write error: Numerical result out of range Similarly, /sys/class/net/XXXXX/tx_queue_len is defined as unsigned: include/linux/netdevice.h: unsigned int tx_queue_len; And has an overflow check: dev_change_tx_queue_len(..., unsigned long new_len): if (new_len != (unsigned int)new_len) return -ERANGE; • https://git.kernel.org/stable/c/d694ad8b7e5004df86ecd415cb2320d543723672 https://git.kernel.org/stable/c/5e753b743d3b38a3e10be666c32c5434423d0093 https://git.kernel.org/stable/c/08062af0a52107a243f7608fd972edb54ca5b7f8 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50017 – x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
https://notcve.org/view.php?id=CVE-2024-50017
In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. • https://git.kernel.org/stable/c/d80a99892f7a992d103138fa4636b2c33abd6740 https://git.kernel.org/stable/c/a23823098ab2c277c14fc110b97d8d5c83597195 https://git.kernel.org/stable/c/cc31744a294584a36bf764a0ffa3255a8e69f036 •