Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()<br /> <br /> On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is<br /> freed via free_transport(), which does not decrement active_num_conn,<br /> leaking this counter.<br /> <br /> Replace free_transport() with ksmbd_tcp_disconnect().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix UAF in xchk_btree_check_block_owner<br /> <br /> We cannot dereference bs-&gt;cur when trying to determine if bs-&gt;cur<br /> aliases bs-&gt;sc-&gt;sa.{bno,rmap}_cur after the latter has been freed.<br /> Fix this by sampling before type before any freeing could happen.<br /> The correct temporal ordering was broken when we removed xfs_btnum_t.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix UAF issue for file-backed mounts w/ directio option<br /> <br /> [ 9.269940][ T3222] Call trace:<br /> [ 9.269948][ T3222] ext4_file_read_iter+0xac/0x108<br /> [ 9.269979][ T3222] vfs_iocb_iter_read+0xac/0x198<br /> [ 9.269993][ T3222] erofs_fileio_rq_submit+0x12c/0x180<br /> [ 9.270008][ T3222] erofs_fileio_submit_bio+0x14/0x24<br /> [ 9.270030][ T3222] z_erofs_runqueue+0x834/0x8ac<br /> [ 9.270054][ T3222] z_erofs_read_folio+0x120/0x220<br /> [ 9.270083][ T3222] filemap_read_folio+0x60/0x120<br /> [ 9.270102][ T3222] filemap_fault+0xcac/0x1060<br /> [ 9.270119][ T3222] do_pte_missing+0x2d8/0x1554<br /> [ 9.270131][ T3222] handle_mm_fault+0x5ec/0x70c<br /> [ 9.270142][ T3222] do_page_fault+0x178/0x88c<br /> [ 9.270167][ T3222] do_translation_fault+0x38/0x54<br /> [ 9.270183][ T3222] do_mem_abort+0x54/0xac<br /> [ 9.270208][ T3222] el0_da+0x44/0x7c<br /> [ 9.270227][ T3222] el0t_64_sync_handler+0x5c/0xf4<br /> [ 9.270253][ T3222] el0t_64_sync+0x1bc/0x1c0<br /> <br /> EROFS may encounter above panic when enabling file-backed mount w/<br /> directio mount option, the root cause is it may suffer UAF in below<br /> race condition:<br /> <br /> - z_erofs_read_folio wq s_dio_done_wq<br /> - z_erofs_runqueue<br /> - erofs_fileio_submit_bio<br /> - erofs_fileio_rq_submit<br /> - vfs_iocb_iter_read<br /> - ext4_file_read_iter<br /> - ext4_dio_read_iter<br /> - iomap_dio_rw<br /> : bio was submitted and return -EIOCBQUEUED<br /> - dio_aio_complete_work<br /> - dio_complete<br /> - dio-&gt;iocb-&gt;ki_complete (erofs_fileio_ki_complete())<br /> - kfree(rq)<br /> : it frees iocb, iocb.ki_filp can be UAF in file_accessed().<br /> - file_accessed<br /> : access NULL file point<br /> <br /> Introduce a reference count in struct erofs_fileio_rq, and initialize it<br /> as two, both erofs_fileio_ki_complete() and erofs_fileio_rq_submit() will<br /> decrease reference count, the last one decreasing the reference count<br /> to zero will free rq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/mmcid: Don&amp;#39;t assume CID is CPU owned on mode switch<br /> <br /> Shinichiro reported a KASAN UAF, which is actually an out of bounds access<br /> in the MMCID management code.<br /> <br /> CPU0 CPU1<br /> T1 runs in userspace<br /> T0: fork(T4) -&gt; Switch to per CPU CID mode<br /> fixup() set MM_CID_TRANSIT on T1/CPU1<br /> T4 exit()<br /> T3 exit()<br /> T2 exit()<br /> T1 exit() switch to per task mode<br /> ---&gt; Out of bounds access.<br /> <br /> As T1 has not scheduled after T0 set the TRANSIT bit, it exits with the<br /> TRANSIT bit set. sched_mm_cid_remove_user() clears the TRANSIT bit in<br /> the task and drops the CID, but it does not touch the per CPU storage.<br /> That&amp;#39;s functionally correct because a CID is only owned by the CPU when<br /> the ONCPU bit is set, which is mutually exclusive with the TRANSIT flag.<br /> <br /> Now sched_mm_cid_exit() assumes that the CID is CPU owned because the<br /> prior mode was per CPU. It invokes mm_drop_cid_on_cpu() which clears the<br /> not set ONCPU bit and then invokes clear_bit() with an insanely large<br /> bit number because TRANSIT is set (bit 29).<br /> <br /> Prevent that by actually validating that the CID is CPU owned in<br /> mm_drop_cid_on_cpu().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: add chann_lock to protect ksmbd_chann_list xarray<br /> <br /> ksmbd_chann_list xarray lacks synchronization, allowing use-after-free in<br /> multi-channel sessions (between lookup_chann_list() and ksmbd_chann_del).<br /> <br /> Adds rw_semaphore chann_lock to struct ksmbd_session and protects<br /> all xa_load/xa_store/xa_erase accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/exynos: vidi: use ctx-&gt;lock to protect struct vidi_context member variables related to memory alloc/free<br /> <br /> Exynos Virtual Display driver performs memory alloc/free operations<br /> without lock protection, which easily causes concurrency problem.<br /> <br /> For example, use-after-free can occur in race scenario like this:<br /> ```<br /> CPU0 CPU1 CPU2<br /> ---- ---- ----<br /> vidi_connection_ioctl()<br /> if (vidi-&gt;connection) // true<br /> drm_edid = drm_edid_alloc(); // alloc drm_edid<br /> ...<br /> ctx-&gt;raw_edid = drm_edid;<br /> ...<br /> drm_mode_getconnector()<br /> drm_helper_probe_single_connector_modes()<br /> vidi_get_modes()<br /> if (ctx-&gt;raw_edid) // true<br /> drm_edid_dup(ctx-&gt;raw_edid);<br /> if (!drm_edid) // false<br /> ...<br /> vidi_connection_ioctl()<br /> if (vidi-&gt;connection) // false<br /> drm_edid_free(ctx-&gt;raw_edid); // free drm_edid<br /> ...<br /> drm_edid_alloc(drm_edid-&gt;edid)<br /> kmemdup(edid); // UAF!!<br /> ...<br /> ```<br /> <br /> To prevent these vulns, at least in vidi_context, member variables related<br /> to memory alloc/free should be protected with ctx-&gt;lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: split cached_fid bitfields to avoid shared-byte RMW races<br /> <br /> is_open, has_lease and on_list are stored in the same bitfield byte in<br /> struct cached_fid but are updated in different code paths that may run<br /> concurrently. Bitfield assignments generate byte read–modify–write<br /> operations (e.g. `orb $mask, addr` on x86_64), so updating one flag can<br /> restore stale values of the others.<br /> <br /> A possible interleaving is:<br /> CPU1: load old byte (has_lease=1, on_list=1)<br /> CPU2: clear both flags (store 0)<br /> CPU1: RMW store (old | IS_OPEN) -&gt; reintroduces cleared bits<br /> <br /> To avoid this class of races, convert these flags to separate bool<br /> fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: fsl-mc: fix use-after-free in driver_override_show()<br /> <br /> The driver_override_show() function reads the driver_override string<br /> without holding the device_lock. However, driver_override_store() uses<br /> driver_set_override(), which modifies and frees the string while holding<br /> the device_lock.<br /> <br /> This can result in a concurrent use-after-free if the string is freed<br /> by the store function while being read by the show function.<br /> <br /> Fix this by holding the device_lock around the read operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths<br /> <br /> The problem occurs when a signed request fails smb2 signature verification<br /> check. In __process_request(), if check_sign_req() returns an error,<br /> set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called.<br /> set_smb2_rsp_status() set work-&gt;next_smb2_rcv_hdr_off as zero. By resetting<br /> next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain<br /> is lost. Consequently, is_chained_smb2_message() continues to point to<br /> the same request header instead of advancing. If the header&amp;#39;s NextCommand<br /> field is non-zero, the function returns true, causing __handle_ksmbd_work()<br /> to repeatedly process the same failed request in an infinite loop.<br /> This results in the kernel log being flooded with "bad smb2 signature"<br /> messages and high CPU usage.<br /> <br /> This patch fixes the issue by changing the return value from<br /> SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that<br /> the processing loop terminates immediately rather than attempting to<br /> continue from an invalidated offset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly<br /> <br /> The existing allocation of scatterlists in omap_crypto_copy_sg_lists()<br /> was allocating an array of scatterlist pointers, not scatterlist objects,<br /> resulting in a 4x too small allocation.<br /> <br /> Use sizeof(*new_sg) to get the correct object size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: Fix potential block overflow that cause system hang<br /> <br /> When a user executes the FITRIM command, an underflow can occur when<br /> calculating nblocks if end_block is too small. Since nblocks is of<br /> type sector_t, which is u64, a negative nblocks value will become a<br /> very large positive integer. This ultimately leads to the block layer<br /> function __blkdev_issue_discard() taking an excessively long time to<br /> process the bio chain, and the ns_segctor_sem lock remains held for a<br /> long period. This prevents other tasks from acquiring the ns_segctor_sem<br /> lock, resulting in the hang reported by syzbot in [1].<br /> <br /> If the ending block is too small, typically if it is smaller than 4KiB<br /> range, depending on the usage of the segment 0, it may be possible to<br /> attempt a discard request beyond the device size causing the hang.<br /> <br /> Exiting successfully and assign the discarded size (0 in this case)<br /> to range-&gt;len.<br /> <br /> Although the start and len values in the user input range are too small,<br /> a conservative strategy is adopted here to safely ignore them, which is<br /> equivalent to a no-op; it will not perform any trimming and will not<br /> throw an error.<br /> <br /> [1]<br /> task:segctord state:D stack:28968 pid:6093 tgid:6093 ppid:2 task_flags:0x200040 flags:0x00080000<br /> Call Trace:<br /> rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272<br /> nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357<br /> nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline]<br /> nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684<br /> <br /> [ryusuke: corrected part of the commit message about the consequences]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Validate sp before freeing associated memory<br /> <br /> System crash with the following signature<br /> [154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete<br /> [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3.<br /> [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5.<br /> [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 0080 0000.<br /> [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 00a0 0000.<br /> [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate).<br /> [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate).<br /> [154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8<br /> [154565.553080] #PF: supervisor read access in kernel mode<br /> [154565.553082] #PF: error_code(0x0000) - not-present page<br /> [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0<br /> [154565.553089] Oops: 0000 1 PREEMPT SMP PTI<br /> [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1<br /> [154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024<br /> [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx]<br /> [154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b<br /> [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286<br /> [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002<br /> [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47<br /> [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a<br /> [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0<br /> [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000<br /> [154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000<br /> [154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0<br /> [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [154565.553159] PKRU: 55555554<br /> [154565.553160] Call Trace:<br /> [154565.553162] <br /> [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df<br /> [154565.553172] ? show_trace_log_lvl+0x1c4/0x2df<br /> [154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx]<br /> [154565.553215] ? __die_body.cold+0x8/0xd<br /> [154565.553218] ? page_fault_oops+0x134/0x170<br /> [154565.553223] ? snprintf+0x49/0x70<br /> [154565.553229] ? exc_page_fault+0x62/0x150<br /> [154565.553238] ? asm_exc_page_fault+0x22/0x30<br /> <br /> Check for sp being non NULL before freeing any associated memory