CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42075 – bpf: Fix remap of arena.
https://notcve.org/view.php?id=CVE-2024-42075
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix remap of arena. The bpf arena logic didn't account for mremap operation. Add a refcnt for multiple mmap events to prevent use-after-free in arena_vm_close. • https://git.kernel.org/stable/c/317460317a02a1af512697e6e964298dedd8a163 https://git.kernel.org/stable/c/87496a1b01e8e2e399428c0db25e106f7961d01e https://git.kernel.org/stable/c/b90d77e5fd784ada62ddd714d15ee2400c28e1cf •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42074 – ASoC: amd: acp: add a null check for chip_pdev structure
https://notcve.org/view.php?id=CVE-2024-42074
In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp: add a null check for chip_pdev structure When acp platform device creation is skipped, chip->chip_pdev value will remain NULL. Add NULL check for chip->chip_pdev structure in snd_acp_resume() function to avoid null pointer dereference. • https://git.kernel.org/stable/c/088a40980efbc2c449b72f0f2c7ebd82f71d08e2 https://git.kernel.org/stable/c/e158ed266fc1adfa456880fb6dabce2e5623843b https://git.kernel.org/stable/c/b0c39ae1cc86afe74aa2f6273ccb514f8d180cf6 https://git.kernel.org/stable/c/98d919dfee1cc402ca29d45da642852d7c9a2301 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42073 – mlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems
https://notcve.org/view.php?id=CVE-2024-42073
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems The following two shared buffer operations make use of the Shared Buffer Status Register (SBSR): # devlink sb occupancy snapshot pci/0000:01:00.0 # devlink sb occupancy clearmax pci/0000:01:00.0 The register has two masks of 256 bits to denote on which ingress / egress ports the register should operate on. Spectrum-4 has more than 256 ports, so the register was extended by cited commit with a new 'port_page' field. However, when filling the register's payload, the driver specifies the ports as absolute numbers and not relative to the first port of the port page, resulting in memory corruptions [1]. Fix by specifying the ports relative to the first port of the port page. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0 Read of size 1 at addr ffff8881068cb00f by task devlink/1566 [...] Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0 mlxsw_devlink_sb_occ_snapshot+0x75/0xb0 devlink_nl_sb_occ_snapshot_doit+0x1f9/0x2a0 genl_family_rcv_msg_doit+0x20c/0x300 genl_rcv_msg+0x567/0x800 netlink_rcv_skb+0x170/0x450 genl_rcv+0x2d/0x40 netlink_unicast+0x547/0x830 netlink_sendmsg+0x8d4/0xdb0 __sys_sendto+0x49b/0x510 __x64_sys_sendto+0xe5/0x1c0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...] Allocated by task 1: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 copy_verifier_state+0xbc2/0xfb0 do_check_common+0x2c51/0xc7e0 bpf_check+0x5107/0x9960 bpf_prog_load+0xf0e/0x2690 __sys_bpf+0x1a61/0x49d0 __x64_sys_bpf+0x7d/0xc0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 1: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x109/0x170 __kasan_slab_free+0x14/0x30 kfree+0xca/0x2b0 free_verifier_state+0xce/0x270 do_check_common+0x4828/0xc7e0 bpf_check+0x5107/0x9960 bpf_prog_load+0xf0e/0x2690 __sys_bpf+0x1a61/0x49d0 __x64_sys_bpf+0x7d/0xc0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f • https://git.kernel.org/stable/c/f8538aec88b46642553a9ba9efa0952f5958dbed https://git.kernel.org/stable/c/bfa86a96912faa0b6142a918db88cc0c738a769e https://git.kernel.org/stable/c/942901e0fc74ad4b7992ef7ca9336e68d5fd6d36 https://git.kernel.org/stable/c/bf8781ede7bd9a37c0fcabca78976e61300b5a1a https://git.kernel.org/stable/c/c28947de2bed40217cf256c5d0d16880054fcf13 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42072 – bpf: Fix may_goto with negative offset.
https://notcve.org/view.php?id=CVE-2024-42072
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix may_goto with negative offset. Zac's syzbot crafted a bpf prog that exposed two bugs in may_goto. The 1st bug is the way may_goto is patched. When offset is negative it should be patched differently. The 2nd bug is in the verifier: when current state may_goto_depth is equal to visited state may_goto_depth it means there is an actual infinite loop. It's not correct to prune exploration of the program at this point. Note, that this check doesn't limit the program to only one may_goto insn, since 2nd and any further may_goto will increment may_goto_depth only in the queued state pushed for future exploration. The current state will have may_goto_depth == 0 regardless of number of may_goto insns and the verifier has to explore the program until bpf_exit. • https://git.kernel.org/stable/c/011832b97b311bb9e3c27945bc0d1089a14209c9 https://git.kernel.org/stable/c/175827e04f4be53f3dfb57edf12d0d49b18fd939 https://git.kernel.org/stable/c/2b2efe1937ca9f8815884bd4dcd5b32733025103 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42071 – ionic: use dev_consume_skb_any outside of napi
https://notcve.org/view.php?id=CVE-2024-42071
In the Linux kernel, the following vulnerability has been resolved: ionic: use dev_consume_skb_any outside of napi If we're not in a NAPI softirq context, we need to be careful about how we call napi_consume_skb(), specifically we need to call it with budget==0 to signal to it that we're not in a safe context. This was found while running some configuration stress testing of traffic and a change queue config loop running, and this curious note popped out: [ 4371.402645] BUG: using smp_processor_id() in preemptible [00000000] code: ethtool/20545 [ 4371.402897] caller is napi_skb_cache_put+0x16/0x80 [ 4371.403120] CPU: 25 PID: 20545 Comm: ethtool Kdump: loaded Tainted: G OE 6.10.0-rc3-netnext+ #8 [ 4371.403302] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 01/23/2021 [ 4371.403460] Call Trace: [ 4371.403613] <TASK> [ 4371.403758] dump_stack_lvl+0x4f/0x70 [ 4371.403904] check_preemption_disabled+0xc1/0xe0 [ 4371.404051] napi_skb_cache_put+0x16/0x80 [ 4371.404199] ionic_tx_clean+0x18a/0x240 [ionic] [ 4371.404354] ionic_tx_cq_service+0xc4/0x200 [ionic] [ 4371.404505] ionic_tx_flush+0x15/0x70 [ionic] [ 4371.404653] ? ionic_lif_qcq_deinit.isra.23+0x5b/0x70 [ionic] [ 4371.404805] ionic_txrx_deinit+0x71/0x190 [ionic] [ 4371.404956] ionic_reconfigure_queues+0x5f5/0xff0 [ionic] [ 4371.405111] ionic_set_ringparam+0x2e8/0x3e0 [ionic] [ 4371.405265] ethnl_set_rings+0x1f1/0x300 [ 4371.405418] ethnl_default_set_doit+0xbb/0x160 [ 4371.405571] genl_family_rcv_msg_doit+0xff/0x130 [...] I found that ionic_tx_clean() calls napi_consume_skb() which calls napi_skb_cache_put(), but before that last call is the note /* Zero budget indicate non-NAPI context called us, like netpoll */ and DEBUG_NET_WARN_ON_ONCE(!in_softirq()); Those are pretty big hints that we're doing it wrong. We can pass a context hint down through the calls to let ionic_tx_clean() know what we're doing so it can call napi_consume_skb() correctly. • https://git.kernel.org/stable/c/386e69865311044b576ff536c99c6ee9cc98a228 https://git.kernel.org/stable/c/ef7646ed49fff962e97b276f4ab91327a67eeb5a https://git.kernel.org/stable/c/84b767f9e34fdb143c09e66a2a20722fc2921821 •