Vulnerabilidades

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: add a permission check for FSCTL_SET_ZERO_DATA<br /> <br /> FSCTL_SET_ZERO_DATA in smb2_ioctl() destroys file data via<br /> ksmbd_vfs_zero_data() -&gt; vfs_fallocate(PUNCH_HOLE/ZERO_RANGE) after<br /> checking only the share-level KSMBD_TREE_CONN_FLAG_WRITABLE, with no<br /> per-handle access check. A handle opened with only FILE_WRITE_ATTRIBUTES<br /> still yields an FMODE_WRITE filp (FILE_WRITE_ATTRIBUTES is part of<br /> FILE_WRITE_DESIRE_ACCESS_LE, so smb2_create_open_flags() opens it<br /> O_WRONLY), so the vfs_fallocate FMODE_WRITE check does not stop it; only<br /> the missing fp-&gt;daccess gate would. Reproduced on mainline 7.1-rc7 with<br /> KASAN by an authenticated SMB client: a FILE_WRITE_ATTRIBUTES-only handle<br /> zeroed 4096 bytes of file data it had no FILE_WRITE_DATA right to<br /> (6/6; a FILE_READ_DATA-only handle was correctly denied).<br /> <br /> This is the unfixed sibling of commit cc57232cae23 ("ksmbd: fix FSCTL<br /> permission bypass by adding a permission check for FSCTL_SET_SPARSE").<br /> Because SET_ZERO_DATA writes data (not an attribute), require<br /> FILE_WRITE_DATA.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE<br /> <br /> The FSCTL_DUPLICATE_EXTENTS_TO_FILE arm of smb2_ioctl() overwrites the<br /> destination file&amp;#39;s data via vfs_clone_file_range() with neither the<br /> share-level KSMBD_TREE_CONN_FLAG_WRITABLE check nor a per-handle<br /> fp-&gt;daccess check that the other write-bearing arms carry. A client can<br /> overwrite destination data on a read-only share, or from a handle opened<br /> with only FILE_WRITE_ATTRIBUTES (which still yields an FMODE_WRITE filp).<br /> FILE_WRITE_ATTRIBUTES-only destination handle overwrote the file&amp;#39;s data via<br /> the clone. Add both checks, matching the FSCTL_SET_SPARSE permission fix;<br /> require FILE_WRITE_DATA since this writes data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: prevent path traversal bypass by restricting caseless retry<br /> <br /> ksmbd_vfs_path_lookup() enforces LOOKUP_BENEATH to restrict path<br /> resolution within the share root. When a crafted path attempts to<br /> escape the share boundary using parent-directory components (&amp;#39;..&amp;#39;),<br /> vfs_path_parent_lookup() detects this and immediately fails,<br /> returning -EXDEV.<br /> <br /> However, a bug exists in __ksmbd_vfs_kern_path() under caseless mode.<br /> The function fails to intercept the -EXDEV error and erroneously<br /> falls through to the caseless retry logic, which is intended only<br /> for genuinely missing files. During this retry process, the path<br /> is reconstructed, leading to an unintended LOOKUP_BENEATH bypass<br /> that allows write-capable users to create zero-length files or<br /> directories outside the exported share.<br /> <br /> Fix this by ensuring that the execution only proceeds to the caseless<br /> lookup retry when the error is specifically -ENOENT. Any other errors,<br /> such as -EXDEV from a path traversal attempt, must be returned immediately.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: resolve SWN tcon from live registrations<br /> <br /> cifs_swn_notify() looks up a witness registration by id under<br /> cifs_swnreg_idr_mutex, drops the mutex, and then uses the registration&amp;#39;s<br /> cached tcon pointer. That pointer is not a lifetime reference, and it is<br /> not a stable representative once cifs_get_swn_reg() lets multiple tcons<br /> for the same net/share name share one registration id.<br /> <br /> A same-share second mount can keep the cifs_swn_reg alive after the first<br /> tcon unregisters and is freed. The registration then still points at the<br /> freed first tcon, so taking tc_lock or incrementing tc_count through<br /> swnreg-&gt;tcon only moves the use-after-free earlier. Taking tc_lock while<br /> holding cifs_swnreg_idr_mutex also violates the documented CIFS lock<br /> order.<br /> <br /> Fix this by making the registration store only the stable witness<br /> identity: id, net name, share name, and notify flags. When a notify<br /> arrives, copy that identity under cifs_swnreg_idr_mutex, drop the mutex,<br /> then find and pin a live witness tcon that currently matches the net/share<br /> pair under the normal cifs_tcp_ses_lock -&gt; tc_lock order. The notification<br /> path uses that pinned tcon directly and drops the reference when done.<br /> <br /> Registration and unregister messages now use the live tcon passed by the<br /> caller instead of a cached tcon in the registration. The final unregister<br /> send is folded into cifs_swn_unregister() while the registration is still<br /> protected by cifs_swnreg_idr_mutex. This removes the previous<br /> find/drop/reacquire raw-pointer window. The release path only removes the<br /> idr entry and frees the stable identity strings.<br /> <br /> This preserves the intended one-registration/many-tcon behavior: a<br /> registration id represents a net/share pair, and notify handling acts on a<br /> live representative selected at use time. It also preserves CLIENT_MOVE<br /> ordering for the representative tcon because the old-IP unregister is sent<br /> before cifs_swn_register() sends the new-IP register.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()<br /> <br /> When the SMB sink is used as a perf AUX sink, smb_update_buffer() calls<br /> smb_sync_perf_buffer() to copy hardware trace data into the perf AUX ring<br /> buffer pages. It derives pg_idx = head &gt;&gt; PAGE_SHIFT from @head, which is<br /> handle-&gt;head, and indexes dst_pages[pg_idx]. The pg_idx %= nr_pages<br /> normalization is only applied after the first loop iteration.<br /> <br /> This leaves the initial page index underived from the buffer size, which<br /> can result in an out-of-bounds write past dst_pages[] when head exceeds<br /> the AUX buffer size.<br /> <br /> Normalize head modulo the AUX buffer size before deriving the page index<br /> and offset, mirroring tmc_etr_sync_perf_buffer().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: validate option length before reading conf opt value<br /> <br /> l2cap_get_conf_opt() derives the option length from the<br /> attacker-controlled opt-&gt;len field and immediately dereferences<br /> opt-&gt;val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a<br /> raw pointer for the default case) before any caller has confirmed<br /> that opt-&gt;len bytes are present in the buffer. The callers<br /> (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and<br /> l2cap_conf_rfc_get()) only detect a malformed option afterwards, once<br /> the running length has gone negative, by which point the<br /> out-of-bounds read has already executed.<br /> <br /> An existing post-hoc length check keeps the garbage value from being<br /> consumed, so this is not a data leak in the current control flow. It<br /> is still a validate-after-use ordering bug: up to 4 bytes are read<br /> past the end of the buffer before it is known to contain them, and it<br /> is fragile to future changes in the callers.<br /> <br /> Fix it at the source. Pass the end of the buffer into<br /> l2cap_get_conf_opt() and refuse to touch opt-&gt;val unless the full<br /> option (header + value) fits. Each caller computes an end pointer<br /> once before the loop and checks the return value directly instead of<br /> inferring the error from a negative length.