Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: cros_ec: Delay dev_set_drvdata() until probe success<br /> <br /> If ec_device_probe() fails, cros_ec_class_release releases memory for the<br /> cros_ec_dev structure. However, because the drvdata was already set,<br /> sub-drivers like cros_ec_typec can still retrieve the stale pointer via the<br /> platform device. This leads to a use-after-free when cros_ec_typec attempts<br /> to access &amp;typec-&gt;ec-&gt;ec-&gt;dev on a device that has already been released.<br /> Move dev_set_drvdata() to ensure that the pointer is only made available<br /> once all initialization steps have succeeded.<br /> <br /> sysfs: cannot create duplicate filename &amp;#39;/class/chromeos/cros_ec&amp;#39;<br /> Call trace:<br /> sysfs_do_create_link_sd+0x94/0xdc<br /> sysfs_create_link+0x30/0x44<br /> device_add_class_symlinks+0x90/0x13c<br /> device_add+0xf0/0x50c<br /> ec_device_probe+0x150/0x4f0<br /> platform_probe+0xa0/0xe0<br /> ...<br /> BUG: KASAN: invalid-access in __memcpy+0x44/0x230<br /> Write at addr f5ffff809e2d33ac by task kworker/u32:5/125<br /> Pointer tag: [f5], memory tag: [fe]<br /> Tainted : [W]=WARN, [O]=OOT_MODULE<br /> Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3<br /> Workqueue: events_unbound deferred_probe_work_func<br /> Call trace:<br /> __memcpy+0x44/0x230<br /> cros_ec_check_features+0x60/0xcc [cros_ec_proto]<br /> cros_typec_probe+0xe8/0x6e0 [cros_ec_typec]<br /> platform_probe+0xa0/0xe0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()<br /> <br /> iso_conn_big_sync() drops the socket lock to call hci_get_route() and<br /> then re-acquires it, but dereferences iso_pi(sk)-&gt;conn-&gt;hcon afterwards<br /> without re-checking that conn is still valid.<br /> <br /> While the lock is dropped, the connection can be torn down under the<br /> same socket lock: iso_disconn_cfm() -&gt; iso_conn_del() -&gt; iso_chan_del()<br /> sets iso_pi(sk)-&gt;conn to NULL (and the broadcast teardown path can also<br /> clear conn-&gt;hcon on its own). When iso_conn_big_sync() re-acquires the<br /> lock and reads conn-&gt;hcon, conn may be NULL, causing a NULL pointer<br /> dereference (hcon is the first member of struct iso_conn).<br /> <br /> This path is reached from iso_sock_recvmsg() for a PA-sync broadcast<br /> sink socket (BT_SK_DEFER_SETUP | BT_SK_PA_SYNC), so the dropped-lock<br /> window can race with connection teardown driven by controller events.<br /> <br /> Re-validate iso_pi(sk)-&gt;conn and its hcon after re-acquiring the socket<br /> lock and bail out if the connection went away, as already done in the<br /> sibling iso_sock_rebind_bc().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()<br /> <br /> hci_abort_conn() read hci_skb_event(hdev-&gt;sent_cmd) when a connection<br /> was pending, but hdev-&gt;sent_cmd can be NULL while req_status is still<br /> HCI_REQ_PEND, leading to a NULL pointer dereference and a general<br /> protection fault from the hci_rx_work() receive path.<br /> <br /> Instead of inspecting hdev-&gt;sent_cmd, track the in-flight create<br /> connection command with a new per-connection HCI_CONN_CREATE flag and<br /> route all cancellation through hci_cancel_connect_sync(), which<br /> dispatches to a dedicated per-type cancel function. The create command<br /> is in exactly one of two states: still queued, or in flight. The cancel<br /> function holds cmd_sync_work_lock across the whole decision: the worker<br /> takes this lock to dequeue every entry, so while it is held a queued<br /> command cannot start running and an in-flight command cannot complete<br /> and let the next command become pending. This keeps the flag test and<br /> hci_cmd_sync_cancel() atomic with respect to the worker, so a queued<br /> command is simply dequeued, and an in-flight command owned by this<br /> connection is cancelled without the risk of cancelling an unrelated<br /> command that became pending in the meantime. CIS uses the same flag<br /> mechanism via HCI_CONN_CREATE_CIS but cannot be dequeued per-connection.<br /> <br /> hci_acl_create_conn_sync() and hci_le_create_conn_sync() clear<br /> HCI_CONN_CREATE after the create command completes, but the command<br /> status handler can free conn via hci_conn_del() (for example when the<br /> controller rejects the connection) while the worker is still blocked on<br /> the connection complete event. Hold a reference on conn across the<br /> create command so the flag can be cleared without a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: fix UAF in bt_accept_dequeue()<br /> <br /> bt_accept_get() takes a temporary reference before dropping the accept<br /> queue lock. bt_accept_dequeue() currently drops that reference before<br /> bt_accept_unlink(), leaving only the queue reference.<br /> <br /> bt_accept_unlink() drops the queue reference. The subsequent<br /> sock_hold() therefore accesses freed memory if it was the final<br /> reference, as observed by KASAN during listening L2CAP socket cleanup.<br /> <br /> Retain the temporary queue-walk reference through unlink and hand it to<br /> the caller on success. Drop it explicitly on the closed and<br /> not-yet-connected paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v3()<br /> <br /> During the v3 firmware download the controller sends a v3_data_req with a<br /> 32 bit offset and a 16 bit len. nxp_recv_fw_req_v3() checks only the lower<br /> bound of the offset and then sends firmware from that offset.<br /> <br /> nxpdev-&gt;fw_dnld_v3_offset = offset - nxpdev-&gt;fw_v3_offset_correction;<br /> serdev_device_write_buf(nxpdev-&gt;serdev, nxpdev-&gt;fw-&gt;data +<br /> nxpdev-&gt;fw_dnld_v3_offset, len);<br /> <br /> Nothing checks that fw_dnld_v3_offset + len stays within nxpdev-&gt;fw-&gt;size,<br /> so a controller that asks for an offset or length past the firmware image<br /> makes the driver read past the end of nxpdev-&gt;fw-&gt;data and send that<br /> memory back over UART.<br /> <br /> nxp_recv_fw_req_v1() already bounds the same write. Add the equivalent<br /> check to the v3 path, reject the request when it falls outside the firmware<br /> image, and zero len on the error path so the fw_v3_prev_sent bookkeeping at<br /> free_skb stays consistent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: bnep: pin L2CAP connection during netdev registration<br /> <br /> bnep_add_connection() reads the L2CAP connection without holding the<br /> channel lock, then passes its HCI device to register_netdev(). Controller<br /> teardown can clear and release that connection concurrently, leaving the<br /> network device registration path to dereference a freed parent device.<br /> <br /> Take a reference to the L2CAP connection while holding the channel lock.<br /> Retain it until register_netdev() has taken the parent device reference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()<br /> <br /> Every once in a while we see a hung btmtksdio_flush() task:<br /> <br /> INFO: task kworker/u17:0:189 blocked for more than 122 seconds.<br /> __cancel_work_timer+0x3f4/0x460<br /> cancel_work_sync+0x1c/0x2c<br /> btmtksdio_flush+0x2c/0x40<br /> hci_dev_open_sync+0x10c4/0x2190<br /> [..]<br /> <br /> It all boils down to incorrect time_is_before_jiffies() usage in<br /> btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected<br /> to be terminated if running for longer than 5*HZ. However the<br /> timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ)<br /> evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a<br /> timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout)<br /> means that:<br /> - before the 5-second timeout: the condition is `int_status || false`,<br /> so it loops as long as there are pending interrupts.<br /> - after the 5-second timeout: the condition becomes `int_status || true`,<br /> which is always true.<br /> <br /> When the loop becomes infinite btmtksdio_txrx_work() loop never<br /> terminates and never releases the SDIO host.<br /> <br /> Fix loop termination condition to actually enforce a 5*HZ timeout.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: flowtable: IPIP tunnel hardware offload is not yet support<br /> <br /> No driver supports for IPIP tunnels yet, give up early on setting up the<br /> hardware offload for this scenario.<br /> <br /> This patch adds a stub that can be enhanced to add more configuration<br /> that are currently not supported. As of now, the offload work is<br /> enqueued to the worker, then ignored if the hardware offload<br /> configuration is not supported.<br /> <br /> Check the NF_FLOW_HW flag to know if this entry was already tried once<br /> to be offloaded so this is not retried on refresh when unsupported. Move<br /> NF_FLOW_HW flag check to nf_flow_offload_add(). If this NF_FLOW_HW flag<br /> is unset the _del and _stats variants are never called.<br /> <br /> This can be updated later on to skip hardware offload work to be queued<br /> in case hardware offload does not support it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ebtables: terminate table name before find_table_lock()<br /> <br /> update_counters() and compat_update_counters() forward a user-supplied<br /> 32-byte table name to find_table_lock() without NUL-terminating it. On a<br /> lookup miss, find_inlist_lock() calls try_then_request_module(..., "%s%s",<br /> "ebtable_", name), and vsnprintf() reads past the name field and the<br /> stack object until it hits a zero byte.<br /> <br /> BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730)<br /> Read of size 1 at addr ffff8880119dfb20 by task exploit/147<br /> Call Trace:<br /> ...<br /> string (lib/vsprintf.c:648 lib/vsprintf.c:730)<br /> vsnprintf (lib/vsprintf.c:2945)<br /> __request_module (kernel/module/kmod.c:150)<br /> do_update_counters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380)<br /> update_counters (net/bridge/netfilter/ebtables.c:1440)<br /> do_ebt_set_ctl (net/bridge/netfilter/ebtables.c:2573)<br /> nf_setsockopt (net/netfilter/nf_sockopt.c:101)<br /> ip_setsockopt (net/ipv4/ip_sockglue.c:1424)<br /> raw_setsockopt (net/ipv4/raw.c:847)<br /> __sys_setsockopt (net/socket.c:2393)<br /> ...<br /> <br /> compat_do_replace() shares the same unterminated name via<br /> compat_copy_ebt_replace_from_user(); terminate it there too so all<br /> find_table_lock() callers behave alike. The other callers already<br /> terminate the name after the copy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ebtables: module names must be null-terminated<br /> <br /> We need to explicitly check the length, else we may pass non-null<br /> terminated string to request_module().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock cancellation<br /> <br /> When a blocking byte-range lock request is deferred in the<br /> FILE_LOCK_DEFERRED path, ksmbd registers the asynchronous work into<br /> the connection&amp;#39;s async_requests list via setup_async_work(). The cancel<br /> callback smb2_remove_blocked_lock() holds a reference to the flock.<br /> <br /> If the lock waiter is subsequently woken up but the work state is no<br /> longer KSMBD_WORK_ACTIVE (e.g., due to a concurrent cancellation), the<br /> cleanup path calls locks_free_lock(flock) without dequeuing the work from<br /> the async_requests list. Concurrently, smb2_cancel() walks the list<br /> under conn-&gt;request_lock and invokes the cancel callback, which then<br /> dereferences the already freed &amp;#39;flock&amp;#39;. This leads to a slab-use-after-free<br /> inside __wake_up_common.<br /> <br /> Fix this by restructuring the cleanup logic after the worker returns<br /> from ksmbd_vfs_posix_lock_wait(). Move list_del(&amp;smb_lock-&gt;llist) and<br /> release_async_work(work) to the top of the cleanup block. This guarantees<br /> that the async work is completely dequeued and serialized under<br /> conn-&gt;request_lock before locks_free_lock(flock) is called, rendering<br /> the flock unreachable for any concurrent smb2_cancel().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: serialize QUERY_DIRECTORY requests per file<br /> <br /> smb2_query_dir() stores a pointer to its stack-allocated private data in<br /> the ksmbd_file readdir_data. Concurrent QUERY_DIRECTORY requests using the<br /> same file handle can overwrite this pointer while an iterate_dir() callback<br /> is still using it, resulting in a stack use-after-free.<br /> <br /> Add a per-file mutex and hold it while accessing the shared directory<br /> enumeration state. The lock covers scan restart, dot entry state,<br /> readdir_data setup and iteration, and response construction. This prevents<br /> another request from replacing readdir_data.private before the current<br /> request has finished using it and also serializes the shared file position.