Vulnerabilities

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 /> 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 /> 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 /> 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 /> f2fs: fix null-ptr-deref in f2fs_submit_page_bio()<br /> <br /> There&amp;#39;s issue as follows when concurrently installing the f2fs.ko<br /> module and mounting the f2fs file system:<br /> KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]<br /> RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs]<br /> Call Trace:<br /> <br /> f2fs_submit_page_bio+0x126/0x8b0 [f2fs]<br /> __get_meta_page+0x1d4/0x920 [f2fs]<br /> get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs]<br /> validate_checkpoint+0xac/0x290 [f2fs]<br /> f2fs_get_valid_checkpoint+0x207/0x950 [f2fs]<br /> f2fs_fill_super+0x1007/0x39b0 [f2fs]<br /> mount_bdev+0x183/0x250<br /> legacy_get_tree+0xf4/0x1e0<br /> vfs_get_tree+0x88/0x340<br /> do_new_mount+0x283/0x5e0<br /> path_mount+0x2b2/0x15b0<br /> __x64_sys_mount+0x1fe/0x270<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Above issue happens as the biset of the f2fs file system is not<br /> initialized before register "f2fs_fs_type".<br /> To address above issue just register "f2fs_fs_type" at the last in<br /> init_f2fs_fs(). Ensure that all f2fs file system resources are<br /> initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zram: fix NULL pointer in comp_algorithm_show()<br /> <br /> LTP reported a NULL pointer dereference as followed:<br /> <br /> CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3<br /> Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015<br /> pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __pi_strcmp+0x24/0x140<br /> lr : zcomp_available_show+0x60/0x100 [zram]<br /> sp : ffff800088b93b90<br /> x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0<br /> x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000<br /> x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900<br /> x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280<br /> x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c<br /> x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000<br /> Call trace:<br /> __pi_strcmp+0x24/0x140<br /> comp_algorithm_show+0x40/0x70 [zram]<br /> dev_attr_show+0x28/0x80<br /> sysfs_kf_seq_show+0x90/0x140<br /> kernfs_seq_show+0x34/0x48<br /> seq_read_iter+0x1d4/0x4e8<br /> kernfs_fop_read_iter+0x40/0x58<br /> new_sync_read+0x9c/0x168<br /> vfs_read+0x1a8/0x1f8<br /> ksys_read+0x74/0x108<br /> __arm64_sys_read+0x24/0x38<br /> invoke_syscall+0x50/0x120<br /> el0_svc_common.constprop.0+0xc8/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x38/0x138<br /> el0t_64_sync_handler+0xc0/0xc8<br /> el0t_64_sync+0x188/0x190<br /> <br /> The zram-&gt;comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() if<br /> comp_algorithm_set() has not been called. User can access the zram device<br /> by sysfs after device_add_disk(), so there is a time window to trigger the<br /> NULL pointer dereference. Move it ahead device_add_disk() to make sure<br /> when user can access the zram device, it is ready. comp_algorithm_set()<br /> is protected by zram-&gt;init_lock in other places and no such problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs<br /> <br /> Base clocks are the first in being probed and are real dependencies of the<br /> rest of fixed, factor and peripheral clocks. For old ralink SoCs RT2880,<br /> RT305x and RT3883 &amp;#39;xtal&amp;#39; must be defined first since in any other case,<br /> when fixed clocks are probed they are delayed until &amp;#39;xtal&amp;#39; is probed so the<br /> following warning appears:<br /> <br /> WARNING: CPU: 0 PID: 0 at drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138<br /> Modules linked in:<br /> CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.43 #0<br /> Stack : 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000<br /> 80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000<br /> 00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000<br /> 203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009<br /> 00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000<br /> ...<br /> Call Trace:<br /> [] show_stack+0x64/0xf4<br /> [] dump_stack_lvl+0x38/0x60<br /> [] __warn+0x94/0xe4<br /> [] warn_slowpath_fmt+0x60/0x94<br /> [] rt3883_bus_recalc_rate+0x98/0x138<br /> [] __clk_register+0x568/0x688<br /> [] of_clk_hw_register+0x18/0x2c<br /> [] rt2880_clk_of_clk_init_driver+0x18c/0x594<br /> [] of_clk_init+0x1c0/0x23c<br /> [] plat_time_init+0x58/0x18c<br /> [] time_init+0x10/0x6c<br /> [] start_kernel+0x458/0x67c<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> When this driver was mainlined we could not find any active users of old<br /> ralink SoCs so we cannot perform any real tests for them. Now, one user<br /> of a Belkin f9k1109 version 1 device which uses RT3883 SoC appeared and<br /> reported some issues in openWRT:<br /> - https://github.com/openwrt/openwrt/issues/16054<br /> <br /> Thus, define a &amp;#39;rt2880_xtal_recalc_rate()&amp;#39; just returning the expected<br /> frequency 40Mhz and use it along the old ralink SoCs to have a correct<br /> boot trace with no warnings and a working clock plan from the beggining.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Move events notifier registration to be after device registration<br /> <br /> Move pkey change work initialization and cleanup from device resources<br /> stage to notifier stage, since this is the stage which handles this work<br /> events.<br /> <br /> Fix a race between the device deregistration and pkey change work by moving<br /> MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to<br /> ensure that the notifier is deregistered before the device during cleanup.<br /> Which ensures there are no works that are being executed after the<br /> device has already unregistered which can cause the panic below.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1<br /> Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023<br /> Workqueue: events pkey_change_handler [mlx5_ib]<br /> RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib]<br /> Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40<br /> RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36<br /> RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128<br /> RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001<br /> R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000<br /> R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905<br /> FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib]<br /> process_one_work+0x1e8/0x3c0<br /> worker_thread+0x50/0x3b0<br /> ? rescuer_thread+0x380/0x380<br /> kthread+0x149/0x170<br /> ? set_kthread_struct+0x50/0x50<br /> ret_from_fork+0x22/0x30<br /> Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core]<br /> CR2: 0000000000000000<br /> ---[ end trace f6f8be4eae12f7bc ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/tegra241-cmdqv: Fix alignment failure at max_n_shift<br /> <br /> When configuring a kernel with PAGE_SIZE=4KB, depending on its setting of<br /> CONFIG_CMA_ALIGNMENT, VCMDQ_LOG2SIZE_MAX=19 could fail the alignment test<br /> and trigger a WARN_ON:<br /> WARNING: at drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3646<br /> Call trace:<br /> arm_smmu_init_one_queue+0x15c/0x210<br /> tegra241_cmdqv_init_structures+0x114/0x338<br /> arm_smmu_device_probe+0xb48/0x1d90<br /> <br /> Fix it by capping max_n_shift to CMDQ_MAX_SZ_SHIFT as SMMUv3 CMDQ does.