CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-50304 – ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()
https://notcve.org/view.php?id=CVE-2024-50304
In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f • https://git.kernel.org/stable/c/c54419321455631079c7d6e60bc732dd0c5914c5 https://git.kernel.org/stable/c/27c1c98bd3b44b7c5f5c0ecfe1a1ec1240b73829 https://git.kernel.org/stable/c/f20fe2cfe06ca1b008b09da4f2b4e0c5547ccef6 https://git.kernel.org/stable/c/90e0569dd3d32f4f4d2ca691d3fa5a8a14a13c12 •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-50302 – HID: core: zero-initialize the report buffer
https://notcve.org/view.php?id=CVE-2024-50302
In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report. • https://git.kernel.org/stable/c/27ce405039bfe6d3f4143415c638f56a3df77dca https://git.kernel.org/stable/c/b2b6cadad699d44a8a5b2a60f3d960e00d6fb3b7 https://git.kernel.org/stable/c/fe6c9b48ebc920ff21c10c50ab2729440c734254 https://git.kernel.org/stable/c/e7ea60184e1e88a3c9e437b3265cbb6439aa7e26 https://git.kernel.org/stable/c/3f9e88f2672c4635960570ee9741778d4135ecf5 https://git.kernel.org/stable/c/d7dc68d82ab3fcfc3f65322465da3d7031d4ab46 https://git.kernel.org/stable/c/05ade5d4337867929e7ef664e7ac8e0c734f1aaf https://git.kernel.org/stable/c/1884ab3d22536a5c14b17c78c2ce76d17 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50301 – security/keys: fix slab-out-of-bounds in key_task_permission
https://notcve.org/view.php?id=CVE-2024-50301
In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. • https://git.kernel.org/stable/c/b2a4df200d570b2c33a57e1ebfa5896e4bc81b69 https://git.kernel.org/stable/c/c3ce634ad953ce48c75c39bdfd8b711dd95f346f https://git.kernel.org/stable/c/4efb69a0e294ef201bcdf7ce3d6202cd0a545a5d https://git.kernel.org/stable/c/1e4332581cd4eed75aea77af6f66cdcdda8b49b9 https://git.kernel.org/stable/c/199c20fb7499c79557a075dc24e9a7dae7d9f1ce https://git.kernel.org/stable/c/bbad2d5b6c99db468d8f88b6ba6a56ed409b4881 https://git.kernel.org/stable/c/3e79ad156bedf2da0ab909a118d2cec6c9c22b79 https://git.kernel.org/stable/c/e0a317ad68e4ea48a0158187238c5407e •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50299 – sctp: properly validate chunk size in sctp_sf_ootb()
https://notcve.org/view.php?id=CVE-2024-50299
In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/67b9a278b80f71ec62091ded97c6bcbea33b5ec3 https://git.kernel.org/stable/c/9b5d42aeaf1a52f73b003a33da6deef7df34685f https://git.kernel.org/stable/c/40b283ba76665437bc2ac72079c51b57b25bff9e https://git.kernel.org/stable/c/a758aa6a773bb872196bcc3173171ef8996bddf0 https://git.kernel.org/stable/c/bf9bff13225baf5f658577f7d985fc4933d79527 https://git.kernel.org/stable/c/d3fb3cc83cf313e4f87063ce0f3fea76b071567b https://git.kernel.org/stable/c/8820d2d6589f62ee5514793fff9b50c9f •
CVSS: -EPSS: 0%CPEs: 13EXPL: 0CVE-2024-50295 – net: arc: fix the device for dma_map_single/dma_unmap_single
https://notcve.org/view.php?id=CVE-2024-50295
In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8 • https://git.kernel.org/stable/c/f959dcd6ddfd29235030e8026471ac1b022ad2b0 https://git.kernel.org/stable/c/209fcdad57061f30c5acaca4fe3eed36c28c2086 https://git.kernel.org/stable/c/7c4a0c1e82d2694baa39b1dac6057c5d32ecc842 https://git.kernel.org/stable/c/dd47d2fe06390cc0f6252aa5c4a58bd93a11d596 https://git.kernel.org/stable/c/c58022e95bd62435cb05a3a61c24905e3aa6280c https://git.kernel.org/stable/c/6c50a56d2bce24982694c3796de275a6ac0dcac5 https://git.kernel.org/stable/c/4e57482e8440fac7137832629109730ea4b267aa https://git.kernel.org/stable/c/f8763ab3fb866330681715259986abbab •