Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: us122l: Use snd_card_free_when_closed() at disconnection<br /> <br /> The USB disconnect callback is supposed to be short and not too-long<br /> waiting. OTOH, the current code uses snd_card_free() at<br /> disconnection, but this waits for the close of all used fds, hence it<br /> can take long. It eventually blocks the upper layer USB ioctls, which<br /> may trigger a soft lockup.<br /> <br /> An easy workaround is to replace snd_card_free() with<br /> snd_card_free_when_closed(). This variant returns immediately while<br /> the release of resources is done asynchronously by the card device<br /> release at the last close.<br /> <br /> The loop of us122l-&gt;mmap_count check is dropped as well. The check is<br /> useless for the asynchronous operation with *_when_closed().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usx2y: Use snd_card_free_when_closed() at disconnection<br /> <br /> The USB disconnect callback is supposed to be short and not too-long<br /> waiting. OTOH, the current code uses snd_card_free() at<br /> disconnection, but this waits for the close of all used fds, hence it<br /> can take long. It eventually blocks the upper layer USB ioctls, which<br /> may trigger a soft lockup.<br /> <br /> An easy workaround is to replace snd_card_free() with<br /> snd_card_free_when_closed(). This variant returns immediately while<br /> the release of resources is done asynchronously by the card device<br /> release at the last close.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isofs: avoid memory leak in iocharset<br /> <br /> A memleak was found as below:<br /> <br /> unreferenced object 0xffff0000d10164d8 (size 8):<br /> comm "pool-udisksd", pid 108217, jiffies 4295408555<br /> hex dump (first 8 bytes):<br /> 75 74 66 38 00 cc cc cc utf8....<br /> backtrace (crc de430d31):<br /> [] kmemleak_alloc+0xb8/0xc8<br /> [] __kmalloc_node_track_caller_noprof+0x380/0x474<br /> [] kstrdup+0x70/0xfc<br /> [] isofs_parse_param+0x228/0x2c0 [isofs]<br /> [] vfs_parse_fs_param+0xf4/0x164<br /> [] vfs_parse_fs_string+0x8c/0xd4<br /> [] vfs_parse_monolithic_sep+0xb0/0xfc<br /> [] generic_parse_monolithic+0x30/0x3c<br /> [] parse_monolithic_mount_data+0x40/0x4c<br /> [] path_mount+0x6c4/0x9ec<br /> [] do_mount+0xac/0xc4<br /> [] __arm64_sys_mount+0x16c/0x2b0<br /> [] invoke_syscall+0x7c/0x104<br /> [] el0_svc_common.constprop.1+0xe0/0x104<br /> [] do_el0_svc+0x2c/0x38<br /> [] el0_svc+0x3c/0x1b8<br /> <br /> The opt-&gt;iocharset is freed inside the isofs_fill_super function,<br /> But there may be situations where it&amp;#39;s not possible to<br /> enter this function.<br /> <br /> For example, in the get_tree_bdev_flags function,when<br /> encountering the situation where "Can&amp;#39;t mount, would change RO state,"<br /> In such a case, isofs_fill_super will not have the opportunity<br /> to be called,which means that opt-&gt;iocharset will not have the chance<br /> to be freed,ultimately leading to a memory leak.<br /> <br /> Let&amp;#39;s move the memory freeing of opt-&gt;iocharset into<br /> isofs_free_fc function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: kvm: Fix out-of-bounds array access<br /> <br /> In kvm_riscv_vcpu_sbi_init() the entry-&gt;ext_idx can contain an<br /> out-of-bound index. This is used as a special marker for the base<br /> extensions, that cannot be disabled. However, when traversing the<br /> extensions, that special marker is not checked prior indexing the<br /> array.<br /> <br /> Add an out-of-bounds check to the function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix the qp flush warnings in req<br /> <br /> When the qp is in error state, the status of WQEs in the queue should be<br /> set to error. Or else the following will appear.<br /> <br /> [ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe]<br /> [ 920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6<br /> [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65<br /> [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> [ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe]<br /> [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24<br /> [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246<br /> [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008<br /> [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac<br /> [ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450<br /> [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800<br /> [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000<br /> [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000<br /> [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0<br /> [ 920.623680] Call Trace:<br /> [ 920.623815] <br /> [ 920.623933] ? __warn+0x79/0xc0<br /> [ 920.624116] ? rxe_completer+0x989/0xcc0 [rdma_rxe]<br /> [ 920.624356] ? report_bug+0xfb/0x150<br /> [ 920.624594] ? handle_bug+0x3c/0x60<br /> [ 920.624796] ? exc_invalid_op+0x14/0x70<br /> [ 920.624976] ? asm_exc_invalid_op+0x16/0x20<br /> [ 920.625203] ? rxe_completer+0x989/0xcc0 [rdma_rxe]<br /> [ 920.625474] ? rxe_completer+0x329/0xcc0 [rdma_rxe]<br /> [ 920.625749] rxe_do_task+0x80/0x110 [rdma_rxe]<br /> [ 920.626037] rxe_requester+0x625/0xde0 [rdma_rxe]<br /> [ 920.626310] ? rxe_cq_post+0xe2/0x180 [rdma_rxe]<br /> [ 920.626583] ? do_complete+0x18d/0x220 [rdma_rxe]<br /> [ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe]<br /> [ 920.627050] rxe_do_task+0x80/0x110 [rdma_rxe]<br /> [ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120<br /> [ 920.627522] handle_softirqs+0xc2/0x250<br /> [ 920.627728] ? sort_range+0x20/0x20<br /> [ 920.627942] run_ksoftirqd+0x1f/0x30<br /> [ 920.628158] smpboot_thread_fn+0xc7/0x1b0<br /> [ 920.628334] kthread+0xd6/0x100<br /> [ 920.628504] ? kthread_complete_and_exit+0x20/0x20<br /> [ 920.628709] ret_from_fork+0x1f/0x30<br /> [ 920.628892]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()<br /> <br /> cpufreq_cpu_get_raw() may return NULL if the cpu is not in<br /> policy-&gt;cpus cpu mask and it will cause null pointer dereference,<br /> so check NULL for cppc_get_cpu_cost().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()<br /> <br /> cpufreq_cpu_get_raw() may return NULL if the cpu is not in<br /> policy-&gt;cpus cpu mask and it will cause null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/s390: Implement blocking domain<br /> <br /> This fixes a crash when surprise hot-unplugging a PCI device. This crash<br /> happens because during hot-unplug __iommu_group_set_domain_nofail()<br /> attaching the default domain fails when the platform no longer<br /> recognizes the device as it has already been removed and we end up with<br /> a NULL domain pointer and UAF. This is exactly the case referred to in<br /> the second comment in __iommu_device_set_domain() and just as stated<br /> there if we can instead attach the blocking domain the UAF is prevented<br /> as this can handle the already removed device. Implement the blocking<br /> domain to use this handling. With this change, the crash is fixed but<br /> we still hit a warning attempting to change DMA ownership on a blocked<br /> device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> unicode: Fix utf8_load() error path<br /> <br /> utf8_load() requests the symbol "utf8_data_table" and then checks if the<br /> requested UTF-8 version is supported. If it&amp;#39;s unsupported, it tries to<br /> put the data table using symbol_put(). If an unsupported version is<br /> requested, symbol_put() fails like this:<br /> <br /> kernel BUG at kernel/module/main.c:786!<br /> RIP: 0010:__symbol_put+0x93/0xb0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? die+0x2e/0x50<br /> ? do_trap+0xca/0x110<br /> ? do_error_trap+0x65/0x80<br /> ? __symbol_put+0x93/0xb0<br /> ? exc_invalid_op+0x51/0x70<br /> ? __symbol_put+0x93/0xb0<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? __pfx_cmp_name+0x10/0x10<br /> ? __symbol_put+0x93/0xb0<br /> ? __symbol_put+0x62/0xb0<br /> utf8_load+0xf8/0x150<br /> <br /> That happens because symbol_put() expects the unique string that<br /> identify the symbol, instead of a pointer to the loaded symbol. Fix that<br /> by using such string.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: handle NONHEAD !delta[1] lclusters gracefully<br /> <br /> syzbot reported a WARNING in iomap_iter_done:<br /> iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80<br /> ioctl_fiemap fs/ioctl.c:220 [inline]<br /> <br /> Generally, NONHEAD lclusters won&amp;#39;t have delta[1]==0, except for crafted<br /> images and filesystems created by pre-1.0 mkfs versions.<br /> <br /> Previously, it would immediately bail out if delta[1]==0, which led to<br /> inadequate decompressed lengths (thus FIEMAP is impacted). Treat it as<br /> delta[1]=1 to work around these legacy mkfs versions.<br /> <br /> `lclusterbits &gt; 14` is illegal for compact indexes, error out too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix file-backed mounts over FUSE<br /> <br /> syzbot reported a null-ptr-deref in fuse_read_args_fill:<br /> fuse_read_folio+0xb0/0x100 fs/fuse/file.c:905<br /> filemap_read_folio+0xc6/0x2a0 mm/filemap.c:2367<br /> do_read_cache_folio+0x263/0x5c0 mm/filemap.c:3825<br /> read_mapping_folio include/linux/pagemap.h:1011 [inline]<br /> erofs_bread+0x34d/0x7e0 fs/erofs/data.c:41<br /> erofs_read_superblock fs/erofs/super.c:281 [inline]<br /> erofs_fc_fill_super+0x2b9/0x2500 fs/erofs/super.c:625<br /> <br /> Unlike most filesystems, some network filesystems and FUSE need<br /> unavoidable valid `file` pointers for their read I/Os [1].<br /> Anyway, those use cases need to be supported too.<br /> <br /> [1] https://docs.kernel.org/filesystems/vfs.html

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to account dirty data in __get_secs_required()<br /> <br /> It will trigger system panic w/ testcase in [1]:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/segment.c:2752!<br /> RIP: 0010:new_curseg+0xc81/0x2110<br /> Call Trace:<br /> f2fs_allocate_data_block+0x1c91/0x4540<br /> do_write_page+0x163/0xdf0<br /> f2fs_outplace_write_data+0x1aa/0x340<br /> f2fs_do_write_data_page+0x797/0x2280<br /> f2fs_write_single_data_page+0x16cd/0x2190<br /> f2fs_write_cache_pages+0x994/0x1c80<br /> f2fs_write_data_pages+0x9cc/0xea0<br /> do_writepages+0x194/0x7a0<br /> filemap_fdatawrite_wbc+0x12b/0x1a0<br /> __filemap_fdatawrite_range+0xbb/0xf0<br /> file_write_and_wait_range+0xa1/0x110<br /> f2fs_do_sync_file+0x26f/0x1c50<br /> f2fs_sync_file+0x12b/0x1d0<br /> vfs_fsync_range+0xfa/0x230<br /> do_fsync+0x3d/0x80<br /> __x64_sys_fsync+0x37/0x50<br /> x64_sys_call+0x1e88/0x20d0<br /> do_syscall_64+0x4b/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The root cause is if checkpoint_disabling and lfs_mode are both on,<br /> it will trigger OPU for all overwritten data, it may cost more free<br /> segment than expected, so f2fs must account those data correctly to<br /> calculate cosumed free segments later, and return ENOSPC earlier to<br /> avoid run out of free segment during block allocation.<br /> <br /> [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/