Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp-ao: fix use-after-free of key in del_async path<br /> <br /> In tcp_ao_delete_key(), the del_async path skips the current_key<br /> and rnext_key validity checks present in the synchronous path,<br /> assuming these pointers are always NULL on LISTEN sockets. However,<br /> if a key was added with set_current=1/set_rnext=1 while the socket<br /> was in CLOSE state, current_key and rnext_key will be non-NULL<br /> after listen() transitions the socket to LISTEN.<br /> <br /> When such a key is deleted with del_async=1, hlist_del_rcu() and<br /> call_rcu() free the key without clearing the dangling pointers.<br /> After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences<br /> current_key-&gt;sndid and rnext_key-&gt;rcvid from freed slab memory.<br /> <br /> Clear current_key and rnext_key in the del_async path when they<br /> reference the key being deleted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: re-lock request before replacing page cache folio<br /> <br /> fuse_try_move_folio() unlocks the request on entry but does not<br /> re-lock it on the success path. This means fuse_chan_abort() can end the<br /> request and free the fuse_io_args (eg fuse_readpages_end()) while the<br /> subsequent copy chain logic after fuse_try_move_folio() accesses the<br /> fuse_io_args, leading to use-after-free issues.<br /> <br /> Fix this by calling lock_request() before replace_page_cache_folio().<br /> This ensures the request is locked on the success path which will<br /> prevent the fuse_io_args from being freed while the later copying logic<br /> runs, and also ensures that the ap-&gt;folios[i]-&gt;mapping is never null<br /> since ap-&gt;folios[i] will always point to the newfolio after<br /> replace_page_cache_folio().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: veml6075: add bounds check to veml6075_it_ms index<br /> <br /> veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7.<br /> If it returns a value &gt;= 5, this causes an out-of-bounds array access.<br /> Add a bounds check and return -EINVAL if the index is out of range.<br /> <br /> The problem values are reserved so should never be read from the<br /> register. Hence this is hardening against fault device, missprogramming<br /> or bus corruption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ti-ads1298: add bounds check to pga_settings index<br /> <br /> ads1298_pga_settings has 7 elements but ADS1298_MASK_CH_PGA can yield<br /> values 0-7. If it yields a value &gt;= 7, this causes an out-of-bounds<br /> array access. Add a bounds check and return -EINVAL if the index<br /> is out of range.<br /> <br /> Note that the remaining value b111 is reserved so should not be seen<br /> in a correctly functioning system.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write<br /> <br /> A KASAN null-ptr-deref was observed in vcs_notifier():<br /> <br /> BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130<br /> Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {}<br /> <br /> The issue is a race condition in vcs_write(). When the console_lock is<br /> temporarily dropped (to copy data from userspace), the vc_data pointer<br /> obtained from vcs_vc() may become stale. After re-acquiring the lock,<br /> vcs_vc() is called again to re-validate the pointer. If the vc has been<br /> deallocated in the meantime, vcs_vc() returns NULL, and the while loop<br /> breaks (with written &gt; 0). However, after the loop, vcs_scr_updated(vc)<br /> is still called with the now-NULL vc pointer, leading to a null pointer<br /> dereference in the notifier chain (vcs_notifier dereferences param-&gt;vc).<br /> <br /> Fix this by adding a NULL check for vc before calling vcs_scr_updated().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails<br /> <br /> dw8250_probe() registers the 8250 port via serial8250_register_8250_port()<br /> and then, if the device has a clock, registers a clock notifier. If<br /> clk_notifier_register() fails, probe returns the error but leaves the<br /> 8250 port registered. The matching serial8250_unregister_port() lives<br /> in dw8250_remove(), which is not called when probe fails, so the port<br /> slot stays occupied until the device is rebound or the system is<br /> rebooted. The devm-allocated driver data is freed while the port still<br /> references it (via the saved private_data and serial_in/serial_out<br /> callbacks), so any access to that port slot before a rebind is a<br /> use-after-free hazard.<br /> <br /> Unregister the port on the clk_notifier_register() error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: reject non-VALID session in compound request branch<br /> <br /> smb2_check_user_session() takes a shortcut for any operation that is not<br /> the first in a COMPOUND request: it reuses work-&gt;sess (the session bound by<br /> the first operation) and validates only the SessionId, then returns<br /> "valid". It never re-checks work-&gt;sess-&gt;state == SMB2_SESSION_VALID, and a<br /> SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation<br /> value) skips even the id comparison. The standalone path<br /> (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does<br /> enforce the VALID state; the compound branch bypasses all of it.<br /> <br /> A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes<br /> a fresh SMB2_SESSION_IN_PROGRESS session whose sess-&gt;user is still NULL<br /> (-&gt;user is assigned later, by ntlm_authenticate()). Used as operation 1 of<br /> a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX,<br /> \\host\IPC$), the tree-connect then runs on that IN_PROGRESS session and<br /> reaches ksmbd_ipc_tree_connect_request(), which dereferences<br /> user_name(sess-&gt;user) with sess-&gt;user == NULL (transport_ipc.c:687/701/704)<br /> -&gt; remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd<br /> worker for all clients.<br /> <br /> Reject any non-first compound operation that lands on a session which is<br /> not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path<br /> enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session,<br /> but it is never carried as a non-first compound operation, so multi-leg<br /> authentication is unaffected by this check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtiofs: fix UAF on submount umount<br /> <br /> iput() called from fuse_release_end() can Oops if the super block has<br /> already been destroyed. Normally this is prevented by waiting for<br /> num_waiting to go down to zero before commencing with super block shutdown.<br /> <br /> This only works, however, for the last submount instance, as the wait<br /> counter is per connection, not per superblock.<br /> <br /> Revert to using synchronous release requests for the auto_submounts case,<br /> which is virtiofs only at this time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si<br /> <br /> syzbot reported a general protection fault in<br /> vidtv_psi_ts_psi_write_into [1].<br /> <br /> vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does<br /> not check for this before dereferencing the returned pointer to access<br /> the continuity counter. This leads to a general protection fault when<br /> accessing a near-NULL address.<br /> <br /> The root cause is that vidtv_mux_pid_ctx_init() does not check the<br /> return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs.<br /> If the allocation fails, the PID context is never created, but init<br /> returns success. The subsequent vidtv_mux_push_si() call then gets<br /> NULL from vidtv_mux_get_pid_ctx() and crashes.<br /> <br /> Fix both the root cause (add error check in vidtv_mux_pid_ctx_init<br /> for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for<br /> all vidtv_mux_get_pid_ctx() calls.<br /> <br /> [1]<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> Workqueue: events vidtv_mux_tick<br /> RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197<br /> Call Trace:<br /> <br /> vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline]<br /> vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231<br /> vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196<br /> vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rzv2h-ivc: Fix concurrent buffer list access<br /> <br /> The list of buffers (`rzv2h_ivc::buffers.queue`) is protected by a<br /> spinlock (`rzv2h_ivc::buffers.lock`). However, in<br /> `rzv2h_ivc_transfer_buffer()`, which runs in a separate workqueue, the<br /> `list_del()` call is executed without holding the spinlock, which makes<br /> it possible for the list to be concurrently modified<br /> <br /> Fix that by removing a buffer from the list in the lock protected section.<br /> <br /> [assign ivc-&gt;buffers.curr in critical section as reported by Barnabas]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: ov8856: free control handler on error in ov8856_init_controls()<br /> <br /> The control handler wasn&amp;#39;t freed if adding controls failed, add an error<br /> exit label and convert the existing error return to use it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: always recover the gpu<br /> <br /> Previously, in case there was no more work to do, recover worker<br /> wouldn&amp;#39;t trigger recovery and would instead rely on the gpu going to<br /> sleep and then resuming when more work is submitted.<br /> <br /> Recover_worker will first increment the fence of the hung ring so, if<br /> there&amp;#39;s only one job submitted to a ring and that causes an hang, it<br /> will early out.<br /> <br /> There&amp;#39;s no guarantee that the gpu will suspend and resume before more<br /> work is submitted and if the gpu is in a hung state it will stay in that<br /> state and probably trigger a timeout again.<br /> <br /> Just stop checking and always recover the gpu.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/704066/