CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50038 – netfilter: xtables: avoid NFPROTO_UNSPEC where needed
https://notcve.org/view.php?id=CVE-2024-50038
In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git. • https://git.kernel.org/stable/c/0269ea4937343536ec7e85649932bc8c9686ea78 https://git.kernel.org/stable/c/85ff9a0f793ca52c527e75cd40a69c948627ebde https://git.kernel.org/stable/c/8f482bb7e27b37f1f734bb9a8eeb28b23d59d189 https://git.kernel.org/stable/c/997f67d813ce0cf5eb3cdb8f124da68141e91b6c https://git.kernel.org/stable/c/4cdc55ec6222bb195995cc58f7cb46e4d8907056 https://git.kernel.org/stable/c/0bfcb7b71e735560077a42847f69597ec7dcc326 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50035 – ppp: fix ppp_async_encode() illegal access
https://notcve.org/view.php?id=CVE-2024-50035
In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 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:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 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: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/4151ec65abd755133ebec687218fadd2d2631167 https://git.kernel.org/stable/c/8dfe93901b410ae41264087427f3b9f389388f83 https://git.kernel.org/stable/c/30d91a478d58cbae3dbaa8224d17d0d839f0d71b https://git.kernel.org/stable/c/fadf8fdb3110d3138e05c3765f645535434f8d76 https://git.kernel.org/stable/c/ce249a4c68d0ce27a8c5d853338d502e2711a314 https://git.kernel.org/stable/c/8fe992ff3df493d1949922ca234419f3ede08dff https://git.kernel.org/stable/c/c007a14797240607038bd3464501109f4 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 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/464801a0f6ccb52b21faa33bac6014fd74cc5e10 https://git.kernel.org/stable/c/8e0766fcf37ad8eed289dd3853628dd9b01b58b0 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/49f9b726bf2bf3dd2caf0d27cadf4bc1c •
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 •