Vulnerabilities

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.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SDCA: Add allocation failure check for Entity name<br /> <br /> Currently find_sdca_entity_iot() can allocate a string for the<br /> Entity name but it doesn&amp;#39;t check if that allocation succeeded.<br /> Add the missing NULL check after the allocation.

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 /> net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop<br /> <br /> When a standalone IPv6 nexthop object is created with a loopback device<br /> (e.g., "ip -6 nexthop add id 100 dev lo"), fib6_nh_init() misclassifies<br /> it as a reject route. This is because nexthop objects have no destination<br /> prefix (fc_dst=::), causing fib6_is_reject() to match any loopback<br /> nexthop. The reject path skips fib_nh_common_init(), leaving<br /> nhc_pcpu_rth_output unallocated. If an IPv4 route later references this<br /> nexthop, __mkroute_output() dereferences NULL nhc_pcpu_rth_output and<br /> panics.<br /> <br /> Simplify the check in fib6_nh_init() to only match explicit reject<br /> routes (RTF_REJECT) instead of using fib6_is_reject(). The loopback<br /> promotion heuristic in fib6_is_reject() is handled separately by<br /> ip6_route_info_create_nh(). After this change, the three cases behave<br /> as follows:<br /> <br /> 1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"):<br /> RTF_REJECT is set, enters reject path, skips fib_nh_common_init().<br /> No behavior change.<br /> <br /> 2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"):<br /> RTF_REJECT is not set, takes normal path, fib_nh_common_init() is<br /> called. ip6_route_info_create_nh() still promotes it to reject<br /> afterward. nhc_pcpu_rth_output is allocated but unused, which is<br /> harmless.<br /> <br /> 3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"):<br /> RTF_REJECT is not set, takes normal path, fib_nh_common_init() is<br /> called. nhc_pcpu_rth_output is properly allocated, fixing the crash<br /> when IPv4 routes reference this nexthop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: annotate data-races around sk-&gt;sk_{data_ready,write_space}<br /> <br /> skmsg (and probably other layers) are changing these pointers<br /> while other cpus might read them concurrently.<br /> <br /> Add corresponding READ_ONCE()/WRITE_ONCE() annotations<br /> for UDP, TCP and AF_UNIX.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix race in devmap on PREEMPT_RT<br /> <br /> On PREEMPT_RT kernels, the per-CPU xdp_dev_bulk_queue (bq) can be<br /> accessed concurrently by multiple preemptible tasks on the same CPU.<br /> <br /> The original code assumes bq_enqueue() and __dev_flush() run atomically<br /> with respect to each other on the same CPU, relying on<br /> local_bh_disable() to prevent preemption. However, on PREEMPT_RT,<br /> local_bh_disable() only calls migrate_disable() (when<br /> PREEMPT_RT_NEEDS_BH_LOCK is not set) and does not disable<br /> preemption, which allows CFS scheduling to preempt a task during<br /> bq_xmit_all(), enabling another task on the same CPU to enter<br /> bq_enqueue() and operate on the same per-CPU bq concurrently.<br /> <br /> This leads to several races:<br /> <br /> 1. Double-free / use-after-free on bq-&gt;q[]: bq_xmit_all() snapshots<br /> cnt = bq-&gt;count, then iterates bq-&gt;q[0..cnt-1] to transmit frames.<br /> If preempted after the snapshot, a second task can call bq_enqueue()<br /> -&gt; bq_xmit_all() on the same bq, transmitting (and freeing) the<br /> same frames. When the first task resumes, it operates on stale<br /> pointers in bq-&gt;q[], causing use-after-free.<br /> <br /> 2. bq-&gt;count and bq-&gt;q[] corruption: concurrent bq_enqueue() modifying<br /> bq-&gt;count and bq-&gt;q[] while bq_xmit_all() is reading them.<br /> <br /> 3. dev_rx/xdp_prog teardown race: __dev_flush() clears bq-&gt;dev_rx and<br /> bq-&gt;xdp_prog after bq_xmit_all(). If preempted between<br /> bq_xmit_all() return and bq-&gt;dev_rx = NULL, a preempting<br /> bq_enqueue() sees dev_rx still set (non-NULL), skips adding bq to<br /> the flush_list, and enqueues a frame. When __dev_flush() resumes,<br /> it clears dev_rx and removes bq from the flush_list, orphaning the<br /> newly enqueued frame.<br /> <br /> 4. __list_del_clearprev() on flush_node: similar to the cpumap race,<br /> both tasks can call __list_del_clearprev() on the same flush_node,<br /> the second dereferences the prev pointer already set to NULL.<br /> <br /> The race between task A (__dev_flush -&gt; bq_xmit_all) and task B<br /> (bq_enqueue -&gt; bq_xmit_all) on the same CPU:<br /> <br /> Task A (xdp_do_flush) Task B (ndo_xdp_xmit redirect)<br /> ---------------------- --------------------------------<br /> __dev_flush(flush_list)<br /> bq_xmit_all(bq)<br /> cnt = bq-&gt;count /* e.g. 16 */<br /> /* start iterating bq-&gt;q[] */<br /> <br /> bq_enqueue(dev, xdpf)<br /> bq-&gt;count == DEV_MAP_BULK_SIZE<br /> bq_xmit_all(bq, 0)<br /> cnt = bq-&gt;count /* same 16! */<br /> ndo_xdp_xmit(bq-&gt;q[])<br /> /* frames freed by driver */<br /> bq-&gt;count = 0<br /> <br /> ndo_xdp_xmit(bq-&gt;q[])<br /> /* use-after-free: frames already freed! */<br /> <br /> Fix this by adding a local_lock_t to xdp_dev_bulk_queue and acquiring<br /> it in bq_enqueue() and __dev_flush(). These paths already run under<br /> local_bh_disable(), so use local_lock_nested_bh() which on non-RT is<br /> a pure annotation with no overhead, and on PREEMPT_RT provides a<br /> per-CPU sleeping lock that serializes access to the bq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Fix recursive locking in __configfs_open_file()<br /> <br /> In flush_write_buffer, &amp;p-&gt;frag_sem is acquired and then the loaded store<br /> function is called, which, here, is target_core_item_dbroot_store(). This<br /> function called filp_open(), following which these functions were called<br /> (in reverse order), according to the call trace:<br /> <br /> down_read<br /> __configfs_open_file<br /> do_dentry_open<br /> vfs_open<br /> do_open<br /> path_openat<br /> do_filp_open<br /> file_open_name<br /> filp_open<br /> target_core_item_dbroot_store<br /> flush_write_buffer<br /> configfs_write_iter<br /> <br /> target_core_item_dbroot_store() tries to validate the new file path by<br /> trying to open the file path provided to it; however, in this case, the bug<br /> report shows:<br /> <br /> db_root: not a directory: /sys/kernel/config/target/dbroot<br /> <br /> indicating that the same configfs file was tried to be opened, on which it<br /> is currently working on. Thus, it is trying to acquire frag_sem semaphore<br /> of the same file of which it already holds the semaphore obtained in<br /> flush_write_buffer(), leading to acquiring the semaphore in a nested manner<br /> and a possibility of recursive locking.<br /> <br /> Fix this by modifying target_core_item_dbroot_store() to use kern_path()<br /> instead of filp_open() to avoid opening the file using filesystem-specific<br /> function __configfs_open_file(), and further modifying it to make this fix<br /> compatible.