Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()<br /> <br /> set_memory_rox() can fail, leaving memory unprotected.<br /> <br /> Check return and bail out when bpf_jit_binary_lock_ro() returns<br /> an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ionic: use dev_consume_skb_any outside of napi<br /> <br /> If we&amp;#39;re not in a NAPI softirq context, we need to be careful<br /> about how we call napi_consume_skb(), specifically we need to<br /> call it with budget==0 to signal to it that we&amp;#39;re not in a<br /> safe context.<br /> <br /> This was found while running some configuration stress testing<br /> of traffic and a change queue config loop running, and this<br /> curious note popped out:<br /> <br /> [ 4371.402645] BUG: using smp_processor_id() in preemptible [00000000] code: ethtool/20545<br /> [ 4371.402897] caller is napi_skb_cache_put+0x16/0x80<br /> [ 4371.403120] CPU: 25 PID: 20545 Comm: ethtool Kdump: loaded Tainted: G OE 6.10.0-rc3-netnext+ #8<br /> [ 4371.403302] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 01/23/2021<br /> [ 4371.403460] Call Trace:<br /> [ 4371.403613] <br /> [ 4371.403758] dump_stack_lvl+0x4f/0x70<br /> [ 4371.403904] check_preemption_disabled+0xc1/0xe0<br /> [ 4371.404051] napi_skb_cache_put+0x16/0x80<br /> [ 4371.404199] ionic_tx_clean+0x18a/0x240 [ionic]<br /> [ 4371.404354] ionic_tx_cq_service+0xc4/0x200 [ionic]<br /> [ 4371.404505] ionic_tx_flush+0x15/0x70 [ionic]<br /> [ 4371.404653] ? ionic_lif_qcq_deinit.isra.23+0x5b/0x70 [ionic]<br /> [ 4371.404805] ionic_txrx_deinit+0x71/0x190 [ionic]<br /> [ 4371.404956] ionic_reconfigure_queues+0x5f5/0xff0 [ionic]<br /> [ 4371.405111] ionic_set_ringparam+0x2e8/0x3e0 [ionic]<br /> [ 4371.405265] ethnl_set_rings+0x1f1/0x300<br /> [ 4371.405418] ethnl_default_set_doit+0xbb/0x160<br /> [ 4371.405571] genl_family_rcv_msg_doit+0xff/0x130<br /> [...]<br /> <br /> I found that ionic_tx_clean() calls napi_consume_skb() which calls<br /> napi_skb_cache_put(), but before that last call is the note<br /> /* Zero budget indicate non-NAPI context called us, like netpoll */<br /> and<br /> DEBUG_NET_WARN_ON_ONCE(!in_softirq());<br /> <br /> Those are pretty big hints that we&amp;#39;re doing it wrong. We can pass a<br /> context hint down through the calls to let ionic_tx_clean() know what<br /> we&amp;#39;re doing so it can call napi_consume_skb() correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix may_goto with negative offset.<br /> <br /> Zac&amp;#39;s syzbot crafted a bpf prog that exposed two bugs in may_goto.<br /> The 1st bug is the way may_goto is patched. When offset is negative<br /> it should be patched differently.<br /> The 2nd bug is in the verifier:<br /> when current state may_goto_depth is equal to visited state may_goto_depth<br /> it means there is an actual infinite loop. It&amp;#39;s not correct to prune<br /> exploration of the program at this point.<br /> Note, that this check doesn&amp;#39;t limit the program to only one may_goto insn,<br /> since 2nd and any further may_goto will increment may_goto_depth only<br /> in the queued state pushed for future exploration. The current state<br /> will have may_goto_depth == 0 regardless of number of may_goto insns<br /> and the verifier has to explore the program until bpf_exit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd: acp: add a null check for chip_pdev structure<br /> <br /> When acp platform device creation is skipped, chip-&gt;chip_pdev value will<br /> remain NULL. Add NULL check for chip-&gt;chip_pdev structure in<br /> snd_acp_resume() function to avoid null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix remap of arena.<br /> <br /> The bpf arena logic didn&amp;#39;t account for mremap operation. Add a refcnt for<br /> multiple mmap events to prevent use-after-free in arena_vm_close.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix possible double free in error handling path<br /> <br /> When auxiliary_device_add() returns error and then calls<br /> auxiliary_device_uninit(), callback function adev_release<br /> calls kfree(madev). We shouldn&amp;#39;t call kfree(madev) again<br /> in the error handling path. Set &amp;#39;madev&amp;#39; to NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode<br /> <br /> syzbot reported uninit memory usages during map_{lookup,delete}_elem.<br /> <br /> ==========<br /> BUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline]<br /> BUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796<br /> __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline]<br /> dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796<br /> ____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline]<br /> bpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38<br /> ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997<br /> __bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237<br /> ==========<br /> <br /> The reproducer should be in the interpreter mode.<br /> <br /> The C reproducer is trying to run the following bpf prog:<br /> <br /> 0: (18) r0 = 0x0<br /> 2: (18) r1 = map[id:49]<br /> 4: (b7) r8 = 16777216<br /> 5: (7b) *(u64 *)(r10 -8) = r8<br /> 6: (bf) r2 = r10<br /> 7: (07) r2 += -229<br /> ^^^^^^^^^^<br /> <br /> 8: (b7) r3 = 8<br /> 9: (b7) r4 = 0<br /> 10: (85) call dev_map_lookup_elem#1543472<br /> 11: (95) exit<br /> <br /> It is due to the "void *key" (r2) passed to the helper. bpf allows uninit<br /> stack memory access for bpf prog with the right privileges. This patch<br /> uses kmsan_unpoison_memory() to mark the stack as initialized.<br /> <br /> This should address different syzbot reports on the uninit "void *key"<br /> argument during map_{lookup,delete}_elem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()<br /> <br /> set_memory_ro() can fail, leaving memory unprotected.<br /> <br /> Check its return and take it into account as an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers<br /> <br /> register store validation for NFT_DATA_VALUE is conditional, however,<br /> the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This<br /> only requires a new helper function to infer the register type from the<br /> set datatype so this conditional check can be removed. Otherwise,<br /> pointer to chain object can be leaked through the registers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems<br /> <br /> The following two shared buffer operations make use of the Shared Buffer<br /> Status Register (SBSR):<br /> <br /> # devlink sb occupancy snapshot pci/0000:01:00.0<br /> # devlink sb occupancy clearmax pci/0000:01:00.0<br /> <br /> The register has two masks of 256 bits to denote on which ingress /<br /> egress ports the register should operate on. Spectrum-4 has more than<br /> 256 ports, so the register was extended by cited commit with a new<br /> &amp;#39;port_page&amp;#39; field.<br /> <br /> However, when filling the register&amp;#39;s payload, the driver specifies the<br /> ports as absolute numbers and not relative to the first port of the port<br /> page, resulting in memory corruptions [1].<br /> <br /> Fix by specifying the ports relative to the first port of the port page.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0<br /> Read of size 1 at addr ffff8881068cb00f by task devlink/1566<br /> [...]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xc6/0x120<br /> print_report+0xce/0x670<br /> kasan_report+0xd7/0x110<br /> mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0<br /> mlxsw_devlink_sb_occ_snapshot+0x75/0xb0<br /> devlink_nl_sb_occ_snapshot_doit+0x1f9/0x2a0<br /> genl_family_rcv_msg_doit+0x20c/0x300<br /> genl_rcv_msg+0x567/0x800<br /> netlink_rcv_skb+0x170/0x450<br /> genl_rcv+0x2d/0x40<br /> netlink_unicast+0x547/0x830<br /> netlink_sendmsg+0x8d4/0xdb0<br /> __sys_sendto+0x49b/0x510<br /> __x64_sys_sendto+0xe5/0x1c0<br /> do_syscall_64+0xc1/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [...]<br /> Allocated by task 1:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> copy_verifier_state+0xbc2/0xfb0<br /> do_check_common+0x2c51/0xc7e0<br /> bpf_check+0x5107/0x9960<br /> bpf_prog_load+0xf0e/0x2690<br /> __sys_bpf+0x1a61/0x49d0<br /> __x64_sys_bpf+0x7d/0xc0<br /> do_syscall_64+0xc1/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 1:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> poison_slab_object+0x109/0x170<br /> __kasan_slab_free+0x14/0x30<br /> kfree+0xca/0x2b0<br /> free_verifier_state+0xce/0x270<br /> do_check_common+0x4828/0xc7e0<br /> bpf_check+0x5107/0x9960<br /> bpf_prog_load+0xf0e/0x2690<br /> __sys_bpf+0x1a61/0x49d0<br /> __x64_sys_bpf+0x7d/0xc0<br /> do_syscall_64+0xc1/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: can: j1939: Initialize unused data in j1939_send_one()<br /> <br /> syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()<br /> creates full frame including unused data, but it doesn&amp;#39;t initialize<br /> it. This causes the kernel-infoleak issue. Fix this by initializing<br /> unused data.<br /> <br /> [1]<br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]<br /> BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]<br /> BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]<br /> BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]<br /> BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185<br /> instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> copy_to_user_iter lib/iov_iter.c:24 [inline]<br /> iterate_ubuf include/linux/iov_iter.h:29 [inline]<br /> iterate_and_advance2 include/linux/iov_iter.h:245 [inline]<br /> iterate_and_advance include/linux/iov_iter.h:271 [inline]<br /> _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185<br /> copy_to_iter include/linux/uio.h:196 [inline]<br /> memcpy_to_msg include/linux/skbuff.h:4113 [inline]<br /> raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008<br /> sock_recvmsg_nosec net/socket.c:1046 [inline]<br /> sock_recvmsg+0x2c4/0x340 net/socket.c:1068<br /> ____sys_recvmsg+0x18a/0x620 net/socket.c:2803<br /> ___sys_recvmsg+0x223/0x840 net/socket.c:2845<br /> do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939<br /> __sys_recvmmsg net/socket.c:3018 [inline]<br /> __do_sys_recvmmsg net/socket.c:3041 [inline]<br /> __se_sys_recvmmsg net/socket.c:3034 [inline]<br /> __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034<br /> x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:3804 [inline]<br /> slab_alloc_node mm/slub.c:3845 [inline]<br /> kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577<br /> __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668<br /> alloc_skb include/linux/skbuff.h:1313 [inline]<br /> alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504<br /> sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795<br /> sock_alloc_send_skb include/net/sock.h:1842 [inline]<br /> j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]<br /> j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]<br /> j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:745<br /> ____sys_sendmsg+0x877/0xb60 net/socket.c:2584<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638<br /> __sys_sendmsg net/socket.c:2667 [inline]<br /> __do_sys_sendmsg net/socket.c:2676 [inline]<br /> __se_sys_sendmsg net/socket.c:2674 [inline]<br /> __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674<br /> x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Bytes 12-15 of 16 are uninitialized<br /> Memory access of size 16 starts at ffff888120969690<br /> Data copied to user address 00000000200017c0<br /> <br /> CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024

Cross Site Scripting (XSS) vulnerability in AML Surety Eco up to 3.5 allows an attacker to run arbitrary code via crafted GET request using the id parameter.