Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Fix a possible memory leak<br /> <br /> In bnxt_re_setup_chip_ctx() when bnxt_qplib_map_db_bar() fails<br /> driver is not freeing the memory allocated for "rdev-&gt;chip_ctx".

When using IPAuthenticationProvider in ZooKeeper Admin Server there is a possibility of Authentication Bypass by Spoofing -- this only impacts IP based authentication implemented in ZooKeeper Admin Server. Default configuration of client&amp;#39;s IP address detection in IPAuthenticationProvider, which uses HTTP request headers, is weak and allows an attacker to bypass authentication via spoofing client&amp;#39;s IP address in request headers. Default configuration honors X-Forwarded-For HTTP header to read client&amp;#39;s IP address. X-Forwarded-For request header is mainly used by proxy servers to identify the client and can be easily spoofed by an attacker pretending that the request comes from a different IP address. Admin Server commands, such as snapshot and restore arbitrarily can be executed on successful exploitation which could potentially lead to information leakage or service availability issues. Users are recommended to upgrade to version 3.9.3, which fixes this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: systemport: fix potential memory leak in bcm_sysport_xmit()<br /> <br /> The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb<br /> in case of dma_map_single() fails, add dev_kfree_skb() to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop<br /> <br /> Driver waits indefinitely for the fifo occupancy to go below a threshold<br /> as soon as the pacing interrupt is received. This can cause soft lockup on<br /> one of the processors, if the rate of DB is very high.<br /> <br /> Add a loop count for FPGA and exit the __wait_for_fifo_occupancy_below_th<br /> if the loop is taking more time. Pacing will be continuing until the<br /> occupancy is below the threshold. This is ensured by the checks in<br /> bnxt_re_pacing_timer_exp and further scheduling the work for pacing based<br /> on the fifo occupancy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Fix out of bound check<br /> <br /> Driver exports pacing stats only on GenP5 and P7 adapters. But while<br /> parsing the pacing stats, driver has a check for "rdev-&gt;dbr_pacing". This<br /> caused a trace when KASAN is enabled.<br /> <br /> BUG: KASAN: slab-out-of-bounds in bnxt_re_get_hw_stats+0x2b6a/0x2e00 [bnxt_re]<br /> Write of size 8 at addr ffff8885942a6340 by task modprobe/4809

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()<br /> <br /> Clang static checker(scan-build) throws below warning：<br /> | drivers/firmware/arm_scmi/driver.c:line 2915, column 2<br /> | Attempt to free released memory.<br /> <br /> When devm_add_action_or_reset() fails, scmi_debugfs_common_cleanup()<br /> will run twice which causes double free of &amp;#39;dbg-&gt;name&amp;#39;.<br /> <br /> Remove the redundant scmi_debugfs_common_cleanup() to fix this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Check the remaining info_cnt before repeating btf fields<br /> <br /> When trying to repeat the btf fields for array of nested struct, it<br /> doesn&amp;#39;t check the remaining info_cnt. The following splat will be<br /> reported when the value of ret * nelems is greater than BTF_FIELDS_MAX:<br /> <br /> ------------[ cut here ]------------<br /> UBSAN: array-index-out-of-bounds in ../kernel/bpf/btf.c:3951:49<br /> index 11 is out of range for type &amp;#39;btf_field_info [11]&amp;#39;<br /> CPU: 6 UID: 0 PID: 411 Comm: test_progs ...... 6.11.0-rc4+ #1<br /> Tainted: [O]=OOT_MODULE<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x57/0x70<br /> dump_stack+0x10/0x20<br /> ubsan_epilogue+0x9/0x40<br /> __ubsan_handle_out_of_bounds+0x6f/0x80<br /> ? kallsyms_lookup_name+0x48/0xb0<br /> btf_parse_fields+0x992/0xce0<br /> map_create+0x591/0x770<br /> __sys_bpf+0x229/0x2410<br /> __x64_sys_bpf+0x1f/0x30<br /> x64_sys_call+0x199/0x9f0<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7fea56f2cc5d<br /> ......<br /> <br /> ---[ end trace ]---<br /> <br /> Fix it by checking the remaining info_cnt in btf_repeat_fields() before<br /> repeating the btf fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Preserve param-&gt;string when parsing mount options<br /> <br /> In bpf_parse_param(), keep the value of param-&gt;string intact so it can<br /> be freed later. Otherwise, the kmalloc area pointed to by param-&gt;string<br /> will be leaked as shown below:<br /> <br /> unreferenced object 0xffff888118c46d20 (size 8):<br /> comm "new_name", pid 12109, jiffies 4295580214<br /> hex dump (first 8 bytes):<br /> 61 6e 79 00 38 c9 5c 7e any.8.\~<br /> backtrace (crc e1b7f876):<br /> [] kmemleak_alloc+0x4b/0x80<br /> [] __kmalloc_node_track_caller_noprof+0x36e/0x4a0<br /> [] memdup_user+0x32/0xa0<br /> [] strndup_user+0x46/0x60<br /> [] __x64_sys_fsconfig+0x368/0x3d0<br /> [] x64_sys_call+0xff/0x9f0<br /> [] do_syscall_64+0x3b/0xc0<br /> [] entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsl/fman: Fix refcount handling of fman-related devices<br /> <br /> In mac_probe() there are multiple calls to of_find_device_by_node(),<br /> fman_bind() and fman_port_bind() which takes references to of_dev-&gt;dev.<br /> Not all references taken by these calls are released later on error path<br /> in mac_probe() and in mac_remove() which lead to reference leaks.<br /> <br /> Add references release.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix overloading of MEM_UNINIT&amp;#39;s meaning<br /> <br /> Lonial reported an issue in the BPF verifier where check_mem_size_reg()<br /> has the following code:<br /> <br /> if (!tnum_is_const(reg-&gt;var_off))<br /> /* For unprivileged variable accesses, disable raw<br /> * mode so that the program is required to<br /> * initialize all the memory that the helper could<br /> * just partially fill up.<br /> */<br /> meta = NULL;<br /> <br /> This means that writes are not checked when the register containing the<br /> size of the passed buffer has not a fixed size. Through this bug, a BPF<br /> program can write to a map which is marked as read-only, for example,<br /> .rodata global maps.<br /> <br /> The problem is that MEM_UNINIT&amp;#39;s initial meaning that "the passed buffer<br /> to the BPF helper does not need to be initialized" which was added back<br /> in commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type")<br /> got overloaded over time with "the passed buffer is being written to".<br /> <br /> The problem however is that checks such as the above which were added later<br /> via 06c1c049721a ("bpf: allow helpers access to variable memory") set meta<br /> to NULL in order force the user to always initialize the passed buffer to<br /> the helper. Due to the current double meaning of MEM_UNINIT, this bypasses<br /> verifier write checks to the memory (not boundary checks though) and only<br /> assumes the latter memory is read instead.<br /> <br /> Fix this by reverting MEM_UNINIT back to its original meaning, and having<br /> MEM_WRITE as an annotation to BPF helpers in order to then trigger the<br /> BPF verifier checks for writing to memory.<br /> <br /> Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO}<br /> we can access fn-&gt;arg_type[arg - 1] since it must contain a preceding<br /> ARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removed<br /> altogether since we do check both BPF_READ and BPF_WRITE. Same for the<br /> equivalent check_kfunc_mem_size_reg().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: use cond_resched() in nsim_dev_trap_report_work()<br /> <br /> I am still seeing many syzbot reports hinting that syzbot<br /> might fool nsim_dev_trap_report_work() with hundreds of ports [1]<br /> <br /> Lets use cond_resched(), and system_unbound_wq<br /> instead of implicit system_wq.<br /> <br /> [1]<br /> INFO: task syz-executor:20633 blocked for more than 143 seconds.<br /> Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz-executor state:D stack:25856 pid:20633 tgid:20633 ppid:1 flags:0x00004006<br /> ...<br /> NMI backtrace for cpu 1<br /> CPU: 1 UID: 0 PID: 16760 Comm: kworker/1:0 Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: events nsim_dev_trap_report_work<br /> RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:210<br /> Code: 89 fb e8 23 00 00 00 48 8b 3d 04 fb 9c 0c 48 89 de 5b e9 c3 c7 5d 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1e fa 48 8b 04 24 65 48 8b 0c 25 c0 d7 03 00 65 8b 15 60 f0<br /> RSP: 0018:ffffc90000a187e8 EFLAGS: 00000246<br /> RAX: 0000000000000100 RBX: ffffc90000a188e0 RCX: ffff888027d3bc00<br /> RDX: ffff888027d3bc00 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffff88804a2e6000 R08: ffffffff8a4bc495 R09: ffffffff89da3577<br /> R10: 0000000000000004 R11: ffffffff8a4bc2b0 R12: dffffc0000000000<br /> R13: ffff88806573b503 R14: dffffc0000000000 R15: ffff8880663cca00<br /> FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fc90a747f98 CR3: 000000000e734000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 000000000000002b DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> <br /> <br /> __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382<br /> spin_unlock_bh include/linux/spinlock.h:396 [inline]<br /> nsim_dev_trap_report drivers/net/netdevsim/dev.c:820 [inline]<br /> nsim_dev_trap_report_work+0x75d/0xaa0 drivers/net/netdevsim/dev.c:850<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3391<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()<br /> <br /> If the allocation in msm_disp_state_dump_regs() failed then<br /> `block-&gt;state` can be NULL. The msm_disp_state_print_regs() function<br /> _does_ have code to try to handle it with:<br /> <br /> if (*reg)<br /> dump_addr = *reg;<br /> <br /> ...but since "dump_addr" is initialized to NULL the above is actually<br /> a noop. The code then goes on to dereference `dump_addr`.<br /> <br /> Make the function print "Registers not stored" when it sees a NULL to<br /> solve this. Since we&amp;#39;re touching the code, fix<br /> msm_disp_state_print_regs() not to pointlessly take a double-pointer<br /> and properly mark the pointer as `const`.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/619657/