Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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.

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 /> nfsd: Fix cred ref leak in nfsd_nl_threads_set_doit().<br /> <br /> syzbot reported memory leak of struct cred. [0]<br /> <br /> nfsd_nl_threads_set_doit() passes get_current_cred() to<br /> nfsd_svc(), but put_cred() is not called after that.<br /> <br /> The cred is finally passed down to _svc_xprt_create(),<br /> which calls get_cred() with the cred for struct svc_xprt.<br /> <br /> The ownership of the refcount by get_current_cred() is not<br /> transferred to anywhere and is just leaked.<br /> <br /> nfsd_svc() is also called from write_threads(), but it does<br /> not bump file-&gt;f_cred there.<br /> <br /> nfsd_nl_threads_set_doit() is called from sendmsg() and<br /> current-&gt;cred does not go away.<br /> <br /> Let&amp;#39;s use current_cred() in nfsd_nl_threads_set_doit().<br /> <br /> [0]:<br /> BUG: memory leak<br /> unreferenced object 0xffff888108b89480 (size 184):<br /> comm "syz-executor", pid 5994, jiffies 4294943386<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 369454a7):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4958 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> kmem_cache_alloc_noprof+0x412/0x580 mm/slub.c:5270<br /> prepare_creds+0x22/0x600 kernel/cred.c:185<br /> copy_creds+0x44/0x290 kernel/cred.c:286<br /> copy_process+0x7a7/0x2870 kernel/fork.c:2086<br /> kernel_clone+0xac/0x6e0 kernel/fork.c:2651<br /> __do_sys_clone+0x7f/0xb0 kernel/fork.c:2792<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: ucan: Fix infinite loop from zero-length messages<br /> <br /> If a broken ucan device gets a message with the message length field set<br /> to 0, then the driver will loop for forever in<br /> ucan_read_bulk_callback(), hanging the system. If the length is 0, just<br /> skip the message and go on to the next one.<br /> <br /> This has been fixed in the kvaser_usb driver in the past in commit<br /> 0c73772cd2b8 ("can: kvaser_usb: leaf: Fix potential infinite loop in<br /> command parsers"), so there must be some broken devices out there like<br /> this somewhere.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: purge error queues in socket destructors<br /> <br /> When TX timestamping is enabled via SO_TIMESTAMPING, SKBs may be queued<br /> into sk_error_queue and will stay there until consumed. If userspace never<br /> gets to read the timestamps, or if the controller is removed unexpectedly,<br /> these SKBs will leak.<br /> <br /> Fix by adding skb_queue_purge() calls for sk_error_queue in affected<br /> bluetooth destructors. RFCOMM does not currently use sk_error_queue.