CVSS: 6.6EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43830 – leds: trigger: Unregister sysfs attributes before calling deactivate()
https://notcve.org/view.php?id=CVE-2024-43830
In the Linux kernel, the following vulnerability has been resolved: leds: trigger: Unregister sysfs attributes before calling deactivate() Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback. Calling device_remove_groups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data. Move the device_remove_groups() call to before deactivate() to close this race window. This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling device_add_groups(). • https://git.kernel.org/stable/c/a7e7a3156300a7e1982b03cc9cb8fb0c86434c49 https://git.kernel.org/stable/c/c3b7a650c8717aa89df318364609c86cbc040156 https://git.kernel.org/stable/c/d1415125b701ef13370e2761f691ec632a5eb93a https://git.kernel.org/stable/c/09c1583f0e10c918855d6e7540a79461a353e5d6 https://git.kernel.org/stable/c/3fb6a9d67cfd812a547ac73ec02e1077c26c640d https://git.kernel.org/stable/c/734ba6437e80dfc780e9ee9d95f912392d12b5ea https://git.kernel.org/stable/c/cb8aa9d2a4c8a15d6a43ccf901ef3d094aa60374 https://git.kernel.org/stable/c/0788a6f3523d3686a9eed5ea1e6fcce68 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43819 – kvm: s390: Reject memory region operations for ucontrol VMs
https://notcve.org/view.php?id=CVE-2024-43819
In the Linux kernel, the following vulnerability has been resolved: kvm: s390: Reject memory region operations for ucontrol VMs This change rejects the KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM. This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 and would thus result in a null pointer dereference further in. Memory management needs to be performed in userspace and using the ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP. Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2. [frankja@linux.ibm.com: commit message spelling fix, subject prefix fix] • https://git.kernel.org/stable/c/27e0393f15fc8bc855c6a888387ff5ffd2181089 https://git.kernel.org/stable/c/49c9945c054df4c22008e2bf87ca74d3e2507aa6 https://git.kernel.org/stable/c/7816e58967d0e6cadce05c8540b47ed027dc2499 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-43817 – net: missing check virtio
https://notcve.org/view.php?id=CVE-2024-43817
In the Linux kernel, the following vulnerability has been resolved: net: missing check virtio Two missing check in virtio_net_hdr_to_skb() allowed syzbot to crash kernels again 1. After the skb_segment function the buffer may become non-linear (nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere the __skb_linearize function will not be executed, then the buffer will remain non-linear. Then the condition (offset >= skb_headlen(skb)) becomes true, which causes WARN_ON_ONCE in skb_checksum_help. 2. The struct sk_buff and struct virtio_net_hdr members must be mathematically related. (gso_size) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) may be 0 if division is without remainder. offset+2 (4191) > skb_headlen() (1116) WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Modules linked in: CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209 RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001 RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Found by Linux Verification Center (linuxtesting.org) with Syzkaller • https://git.kernel.org/stable/c/0f6925b3e8da0dbbb52447ca8a8b42b371aac7db https://git.kernel.org/stable/c/2789bc090f4a2caef0cceb3f108867de608bb23a https://git.kernel.org/stable/c/16851e34b621bc7e652c508bb28c47948fb86958 https://git.kernel.org/stable/c/a05fb4ac72fb2ddbdcb135c87b0087ac59fa4de4 https://git.kernel.org/stable/c/a36703d08c83b1488a2f2922f0dc4263125ccd2d https://git.kernel.org/stable/c/27874ca77bd2b05a3779c7b3a5c75d8dd7f0b40f https://git.kernel.org/stable/c/5b1997487a3f3373b0f580c8a20b56c1b64b0775 https://git.kernel.org/stable/c/90d41ebe0cd4635f6410471efc1dd71b3 • CWE-130: Improper Handling of Length Parameter Inconsistency •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42322 – ipvs: properly dereference pe in ip_vs_add_service
https://notcve.org/view.php?id=CVE-2024-42322
In the Linux kernel, the following vulnerability has been resolved: ipvs: properly dereference pe in ip_vs_add_service Use pe directly to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression • https://git.kernel.org/stable/c/39b9722315364121c6e2524515a6e95d52287549 https://git.kernel.org/stable/c/3dd428039e06e1967ce294e2cd6342825aaaad77 https://git.kernel.org/stable/c/c420cd5d5bc6797f3a8824e7d74f38f0c286fca5 https://git.kernel.org/stable/c/cbd070a4ae62f119058973f6d2c984e325bce6e7 https://access.redhat.com/security/cve/CVE-2024-42322 https://bugzilla.redhat.com/show_bug.cgi?id=2305467 •
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 •