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: 4EXPL: 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/b2c664df3bb46aabac6a5fd78aaa5bd614cfad97 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: 4EXPL: 0CVE-2024-42321 – net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE
https://notcve.org/view.php?id=CVE-2024-42321
In the Linux kernel, the following vulnerability has been resolved: net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE The following splat is easy to reproduce upstream as well as in -stable kernels. Florian Westphal provided the following commit: d1dab4f71d37 ("net: add and use __skb_get_hash_symmetric_net") but this complementary fix has been also suggested by Willem de Bruijn and it can be easily backported to -stable kernel which consists in using DEBUG_NET_WARN_ON_ONCE instead to silence the following splat given __skb_get_hash() is used by the nftables tracing infrastructure to to identify packets in traces. [69133.561393] ------------[ cut here ]------------ [69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/ [...] [69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379 [69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0 [69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8 [69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246 [69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19 [69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418 [69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000 [69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400 [69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28 [69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0 [69133.562040] Call Trace: [69133.562044] <IRQ> [69133.562049] ? __warn+0x9f/0x1a0 [ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860 [...] [ 1211.841496] ? bpf_flow_dissect+0x160/0x160 [ 1211.841753] __skb_get_hash+0x97/0x280 [ 1211.841765] ? • https://git.kernel.org/stable/c/9b52e3f267a6835efd50ed9002d530666d16a411 https://git.kernel.org/stable/c/eb03d9826aa646577342a952d658d4598381c035 https://git.kernel.org/stable/c/4afbac11f2f629d1e62817c4e210bdfaa7521107 https://git.kernel.org/stable/c/c5d21aabf1b31a79f228508af33aee83456bc1b0 https://git.kernel.org/stable/c/120f1c857a73e52132e473dee89b340440cb692b •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42320 – s390/dasd: fix error checks in dasd_copy_pair_store()
https://notcve.org/view.php?id=CVE-2024-42320
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error checks in dasd_copy_pair_store() dasd_add_busid() can return an error via ERR_PTR() if an allocation fails. However, two callsites in dasd_copy_pair_store() do not check the result, potentially resulting in a NULL pointer dereference. Fix this by checking the result with IS_ERR() and returning the error up the stack. • https://git.kernel.org/stable/c/a91ff09d39f9b6545254839ac91f1ff7bd21d39e https://git.kernel.org/stable/c/932600a295cc299d470ca7f5d6491bd0dfc99ea7 https://git.kernel.org/stable/c/cc8b7284d5076722e0b8062373b68d8e47c3bace https://git.kernel.org/stable/c/e511167e65d332d07b3c7a3d5a741ee9c19a8c27 https://git.kernel.org/stable/c/68d4c3722290ad300c295fb3435e835d200d5cb2 https://git.kernel.org/stable/c/8e64d2356cbc800b4cd0e3e614797f76bcf0cdb8 •