CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43818 – ASoC: amd: Adjust error handling in case of absent codec device
https://notcve.org/view.php?id=CVE-2024-43818
In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: Adjust error handling in case of absent codec device acpi_get_first_physical_node() can return NULL in several cases (no such device, ACPI table error, reference count drop to 0, etc). Existing check just emit error message, but doesn't perform return. Then this NULL pointer is passed to devm_acpi_dev_add_driver_gpios() where it is dereferenced. Adjust this error handling by adding error code return. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/02527c3f2300100a25524c8c020d98c7957e485e https://git.kernel.org/stable/c/1ba9856cf7f6492b47c1edf853137f320d583db5 https://git.kernel.org/stable/c/99b642dac24f6d09ba3ebf1d690be8aefff86164 https://git.kernel.org/stable/c/b1173d64edd276c957b6d09e1f971c85b38f1519 https://git.kernel.org/stable/c/5080808c3339de2220c602ab7c7fa23dc6c1a5a3 •
CVSS: -EPSS: 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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43816 – scsi: lpfc: Revise lpfc_prep_embed_io routine with proper endian macro usages
https://notcve.org/view.php?id=CVE-2024-43816
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Revise lpfc_prep_embed_io routine with proper endian macro usages On big endian architectures, it is possible to run into a memory out of bounds pointer dereference when FCP targets are zoned. In lpfc_prep_embed_io, the memcpy(ptr, fcp_cmnd, sgl->sge_len) is referencing a little endian formatted sgl->sge_len value. So, the memcpy can cause big endian systems to crash. Redefine the *sgl ptr as a struct sli4_sge_le to make it clear that we are referring to a little endian formatted data structure. And, update the routine with proper le32_to_cpu macro usages. • https://git.kernel.org/stable/c/af20bb73ac2591631d504f3f859f073bcdb7e11e https://git.kernel.org/stable/c/9fd003f344d502f65252963169df3dd237054e49 https://git.kernel.org/stable/c/8bc7c617642db6d8d20ee671fb6c4513017e7a7e •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43815 – crypto: mxs-dcp - Ensure payload is zero when using key slot
https://notcve.org/view.php?id=CVE-2024-43815
In the Linux kernel, the following vulnerability has been resolved: crypto: mxs-dcp - Ensure payload is zero when using key slot We could leak stack memory through the payload field when running AES with a key from one of the hardware's key slots. Fix this by ensuring the payload field is set to 0 in such cases. This does not affect the common use case when the key is supplied from main memory via the descriptor payload. • https://git.kernel.org/stable/c/3d16af0b4cfac4b2c3b238e2ec37b38c2f316978 https://git.kernel.org/stable/c/e1640fed0377bf7276efb70d03cb821a6931063d https://git.kernel.org/stable/c/dd52b5eeb0f70893f762da7254e923fd23fd1379 •
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 •