Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Fix invalid wait context in ctx_sched_in()<br /> <br /> Lockdep found a bug in the event scheduling when a pinned event was<br /> failed and wakes up the threads in the ring buffer like below.<br /> <br /> It seems it should not grab a wait-queue lock under perf-context lock.<br /> Let&amp;#39;s do it with irq_work.<br /> <br /> [ 39.913691] =============================<br /> [ 39.914157] [ BUG: Invalid wait context ]<br /> [ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted<br /> [ 39.915271] -----------------------------<br /> [ 39.915731] repro/837 is trying to lock:<br /> [ 39.916191] ffff88801acfabd8 (&amp;event-&gt;waitq){....}-{3:3}, at: __wake_up+0x26/0x60<br /> [ 39.917182] other info that might help us debug this:<br /> [ 39.917761] context-{5:5}<br /> [ 39.918079] 4 locks held by repro/837:<br /> [ 39.918530] #0: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: __perf_event_task_sched_in+0xd1/0xbc0<br /> [ 39.919612] #1: ffff88806ca3c6f8 (&amp;cpuctx_lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1a7/0xbc0<br /> [ 39.920748] #2: ffff88800d91fc18 (&amp;ctx-&gt;lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1f9/0xbc0<br /> [ 39.921819] #3: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: perf_event_wakeup+0x6c/0x470

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: kaweth: validate USB endpoints<br /> <br /> The kaweth driver should validate that the device it is probing has the<br /> proper number and types of USB endpoints it is expecting before it binds<br /> to it. If a malicious device were to not have the same urbs the driver<br /> will crash later on when it blindly accesses these endpoints.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix preempt count leak in napi poll tracepoint<br /> <br /> Using get_cpu() in the tracepoint assignment causes an obvious preempt<br /> count leak because nothing invokes put_cpu() to undo it:<br /> <br /> softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?<br /> <br /> This clearly has seen a lot of testing in the last 3+ years...<br /> <br /> Use smp_processor_id() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: bq257xx: Fix device node reference leak in bq257xx_reg_dt_parse_gpio()<br /> <br /> In bq257xx_reg_dt_parse_gpio(), if fails to get subchild, it returns<br /> without calling of_node_put(child), causing the device node reference<br /> leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: Fix possible oob access in mt76_connac2_mac_write_txwi_80211()<br /> <br /> Check frame length before accessing the mgmt fields in<br /> mt76_connac2_mac_write_txwi_80211 in order to avoid a possible oob<br /> access.<br /> <br /> [fix check to also cover mgmt-&gt;u.action.u.addba_req.capab,<br /> correct Fixes tag]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix use-after-free in pm8001_queue_command()<br /> <br /> Commit e29c47fe8946 ("scsi: pm8001: Simplify pm8001_task_exec()") refactors<br /> pm8001_queue_command(), however it introduces a potential cause of a double<br /> free scenario when it changes the function to return -ENODEV in case of phy<br /> down/device gone state.<br /> <br /> In this path, pm8001_queue_command() updates task status and calls<br /> task_done to indicate to upper layer that the task has been handled.<br /> However, this also frees the underlying SAS task. A -ENODEV is then<br /> returned to the caller. When libsas sas_ata_qc_issue() receives this error<br /> value, it assumes the task wasn&amp;#39;t handled/queued by LLDD and proceeds to<br /> clean up and free the task again, resulting in a double free.<br /> <br /> Since pm8001_queue_command() handles the SAS task in this case, it should<br /> return 0 to the caller indicating that the task has been handled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/rocket: fix unwinding in error path in rocket_probe<br /> <br /> When rocket_core_init() fails (as could be the case with EPROBE_DEFER),<br /> we need to properly unwind by decrementing the counter we just<br /> incremented and if this is the first core we failed to probe, remove the<br /> rocket DRM device with rocket_device_fini() as well. This matches the<br /> logic in rocket_remove(). Failing to properly unwind results in<br /> out-of-bounds accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: equilibrium: fix warning trace on load<br /> <br /> The callback functions &amp;#39;eqbr_irq_mask()&amp;#39; and &amp;#39;eqbr_irq_ack()&amp;#39; are also<br /> called in the callback function &amp;#39;eqbr_irq_mask_ack()&amp;#39;. This is done to<br /> avoid source code duplication. The problem, is that in the function<br /> &amp;#39;eqbr_irq_mask()&amp;#39; also calles the gpiolib function &amp;#39;gpiochip_disable_irq()&amp;#39;<br /> <br /> This generates the following warning trace in the log for every gpio on<br /> load.<br /> <br /> [ 6.088111] ------------[ cut here ]------------<br /> [ 6.092440] WARNING: CPU: 3 PID: 1 at drivers/gpio/gpiolib.c:3810 gpiochip_disable_irq+0x39/0x50<br /> [ 6.097847] Modules linked in:<br /> [ 6.097847] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.59+ #0<br /> [ 6.097847] Tainted: [W]=WARN<br /> [ 6.097847] RIP: 0010:gpiochip_disable_irq+0x39/0x50<br /> [ 6.097847] Code: 39 c6 48 19 c0 21 c6 48 c1 e6 05 48 03 b2 38 03 00 00 48 81 fe 00 f0 ff ff 77 11 48 8b 46 08 f6 c4 02 74 06 f0 80 66 09 fb c3 0b 90 0f 1f 40 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40<br /> [ 6.097847] RSP: 0000:ffffc9000000b830 EFLAGS: 00010046<br /> [ 6.097847] RAX: 0000000000000045 RBX: ffff888001be02a0 RCX: 0000000000000008<br /> [ 6.097847] RDX: ffff888001be9000 RSI: ffff888001b2dd00 RDI: ffff888001be02a0<br /> [ 6.097847] RBP: ffffc9000000b860 R08: 0000000000000000 R09: 0000000000000000<br /> [ 6.097847] R10: 0000000000000001 R11: ffff888001b2a154 R12: ffff888001be0514<br /> [ 6.097847] R13: ffff888001be02a0 R14: 0000000000000008 R15: 0000000000000000<br /> [ 6.097847] FS: 0000000000000000(0000) GS:ffff888041d80000(0000) knlGS:0000000000000000<br /> [ 6.097847] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 6.097847] CR2: 0000000000000000 CR3: 0000000003030000 CR4: 00000000001026b0<br /> [ 6.097847] Call Trace:<br /> [ 6.097847] <br /> [ 6.097847] ? eqbr_irq_mask+0x63/0x70<br /> [ 6.097847] ? no_action+0x10/0x10<br /> [ 6.097847] eqbr_irq_mask_ack+0x11/0x60<br /> <br /> In an other driver (drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c) the<br /> interrupt is not disabled here.<br /> <br /> To fix this, do not call the &amp;#39;eqbr_irq_mask()&amp;#39; and &amp;#39;eqbr_irq_ack()&amp;#39;<br /> function. Implement instead this directly without disabling the interrupts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Add NULL pointer check to trigger_data_free()<br /> <br /> If trigger_data_alloc() fails and returns NULL, event_hist_trigger_parse()<br /> jumps to the out_free error path. While kfree() safely handles a NULL<br /> pointer, trigger_data_free() does not. This causes a NULL pointer<br /> dereference in trigger_data_free() when evaluating<br /> data-&gt;cmd_ops-&gt;set_filter.<br /> <br /> Fix the problem by adding a NULL pointer check to trigger_data_free().<br /> <br /> The problem was found by an experimental code review agent based on<br /> gemini-3.1-pro while reviewing backports into v6.18.y.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: Don&amp;#39;t log plaintext credentials in cifs_set_cifscreds<br /> <br /> When debug logging is enabled, cifs_set_cifscreds() logs the key<br /> payload and exposes the plaintext username and password. Remove the<br /> debug log to avoid exposing credentials.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu()<br /> <br /> l3mdev_master_dev_rcu() can return NULL when the slave device is being<br /> un-slaved from a VRF. All other callers deal with this, but we lost<br /> the fallback to loopback in ip6_rt_pcpu_alloc() -&gt; ip6_rt_get_dev_rcu()<br /> with commit 4832c30d5458 ("net: ipv6: put host and anycast routes on<br /> device with address").<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]<br /> RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418)<br /> Call Trace:<br /> ip6_pol_route (net/ipv6/route.c:2318)<br /> fib6_rule_lookup (net/ipv6/fib6_rules.c:115)<br /> ip6_route_output_flags (net/ipv6/route.c:2607)<br /> vrf_process_v6_outbound (drivers/net/vrf.c:437)<br /> <br /> I was tempted to rework the un-slaving code to clear the flag first<br /> and insert synchronize_rcu() before we remove the upper. But looks like<br /> the explicit fallback to loopback_dev is an established pattern.<br /> And I guess avoiding the synchronize_rcu() is nice, too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: ems_usb: ems_usb_read_bulk_callback(): check the proper length of a message<br /> <br /> When looking at the data in a USB urb, the actual_length is the size of<br /> the buffer passed to the driver, not the transfer_buffer_length which is<br /> set by the driver as the max size of the buffer.<br /> <br /> When parsing the messages in ems_usb_read_bulk_callback() properly check<br /> the size both at the beginning of parsing the message to make sure it is<br /> big enough for the expected structure, and at the end of the message to<br /> make sure we don&amp;#39;t overflow past the end of the buffer for the next<br /> message.