Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: block range must be validated before use in ext4_mb_clear_bb()<br /> <br /> Block range to free is validated in ext4_free_blocks() using<br /> ext4_inode_block_valid() and then it&amp;#39;s passed to ext4_mb_clear_bb().<br /> However in some situations on bigalloc file system the range might be<br /> adjusted after the validation in ext4_free_blocks() which can lead to<br /> troubles on corrupted file systems such as one found by syzkaller that<br /> resulted in the following BUG<br /> <br /> kernel BUG at fs/ext4/ext4.h:3319!<br /> PREEMPT SMP NOPTI<br /> CPU: 28 PID: 4243 Comm: repro Kdump: loaded Not tainted 5.19.0-rc6+ #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014<br /> RIP: 0010:ext4_free_blocks+0x95e/0xa90<br /> Call Trace:<br /> <br /> ? lock_timer_base+0x61/0x80<br /> ? __es_remove_extent+0x5a/0x760<br /> ? __mod_timer+0x256/0x380<br /> ? ext4_ind_truncate_ensure_credits+0x90/0x220<br /> ext4_clear_blocks+0x107/0x1b0<br /> ext4_free_data+0x15b/0x170<br /> ext4_ind_truncate+0x214/0x2c0<br /> ? _raw_spin_unlock+0x15/0x30<br /> ? ext4_discard_preallocations+0x15a/0x410<br /> ? ext4_journal_check_start+0xe/0x90<br /> ? __ext4_journal_start_sb+0x2f/0x110<br /> ext4_truncate+0x1b5/0x460<br /> ? __ext4_journal_start_sb+0x2f/0x110<br /> ext4_evict_inode+0x2b4/0x6f0<br /> evict+0xd0/0x1d0<br /> ext4_enable_quotas+0x11f/0x1f0<br /> ext4_orphan_cleanup+0x3de/0x430<br /> ? proc_create_seq_private+0x43/0x50<br /> ext4_fill_super+0x295f/0x3ae0<br /> ? snprintf+0x39/0x40<br /> ? sget_fc+0x19c/0x330<br /> ? ext4_reconfigure+0x850/0x850<br /> get_tree_bdev+0x16d/0x260<br /> vfs_get_tree+0x25/0xb0<br /> path_mount+0x431/0xa70<br /> __x64_sys_mount+0xe2/0x120<br /> do_syscall_64+0x5b/0x80<br /> ? do_user_addr_fault+0x1e2/0x670<br /> ? exc_page_fault+0x70/0x170<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7fdf4e512ace<br /> <br /> Fix it by making sure that the block range is properly validated before<br /> used every time it changes in ext4_free_blocks() or ext4_mb_clear_bb().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers:md:fix a potential use-after-free bug<br /> <br /> In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and<br /> may cause sh to be released. However, sh is subsequently used in lines<br /> 2886 "if (sh-&gt;batch_head &amp;&amp; sh != sh-&gt;batch_head)". This may result in an<br /> use-after-free bug.<br /> <br /> It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of<br /> the function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: dw-axi-dmac: ignore interrupt if no descriptor<br /> <br /> If the channel has no descriptor and the interrupt is raised then the<br /> kernel will OOPS. Check the result of vchan_next_desc() in the handler<br /> axi_chan_block_xfer_complete() to avoid the error happening.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: dw-axi-dmac: do not print NULL LLI during error<br /> <br /> During debugging we have seen an issue where axi_chan_dump_lli()<br /> is passed a NULL LLI pointer which ends up causing an OOPS due<br /> to trying to get fields from it. Simply print NULL LLI and exit<br /> to avoid this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl: Fix a memory leak in an error handling path<br /> <br /> A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the<br /> error handling path of afu_allocate_irqs().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> habanalabs/gaudi: fix shift out of bounds<br /> <br /> When validating NIC queues, queue offset calculation must be<br /> performed only for NIC queues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE<br /> <br /> There is no corresponding free routine if lpfc_sli4_issue_wqe fails to<br /> issue the CMF WQE in lpfc_issue_cmf_sync_wqe.<br /> <br /> If ret_val is non-zero, then free the iocbq request structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> venus: pm_helpers: Fix warning in OPP during probe<br /> <br /> Fix the following WARN triggered during Venus driver probe on<br /> 5.19.0-rc8-next-20220728:<br /> <br /> WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610<br /> Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor<br /> qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+)<br /> videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched<br /> snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats<br /> drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5<br /> phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro<br /> lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers<br /> qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector<br /> drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6<br /> CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-20220728 #4<br /> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : dev_pm_opp_set_config+0x49c/0x610<br /> lr : dev_pm_opp_set_config+0x58/0x610<br /> sp : ffff8000093c3710<br /> x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00<br /> x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810<br /> x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810<br /> x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000<br /> x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858<br /> x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000<br /> x11: 0000000000000002 x10: 0000000000000a60 x9 : ffff8000093c35c0<br /> x8 : ffff4396c4273700 x7 : ffff43983efca6c0 x6 : ffff43983efca640<br /> x5 : 00000000410fd0d0 x4 : ffff4396c4272c40 x3 : ffffbca3f5d1e008<br /> x2 : 0000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860<br /> Call trace:<br /> dev_pm_opp_set_config+0x49c/0x610<br /> devm_pm_opp_set_config+0x18/0x70<br /> vcodec_domains_get+0xb8/0x1638 [venus_core]<br /> core_get_v4+0x1d8/0x218 [venus_core]<br /> venus_probe+0xf4/0x468 [venus_core]<br /> platform_probe+0x68/0xd8<br /> really_probe+0xbc/0x2a8<br /> __driver_probe_device+0x78/0xe0<br /> driver_probe_device+0x3c/0xf0<br /> __driver_attach+0x70/0x120<br /> bus_for_each_dev+0x70/0xc0<br /> driver_attach+0x24/0x30<br /> bus_add_driver+0x150/0x200<br /> driver_register+0x64/0x120<br /> __platform_driver_register+0x28/0x38<br /> qcom_venus_driver_init+0x24/0x1000 [venus_core]<br /> do_one_initcall+0x54/0x1c8<br /> do_init_module+0x44/0x1d0<br /> load_module+0x16c8/0x1aa0<br /> __do_sys_finit_module+0xbc/0x110<br /> __arm64_sys_finit_module+0x20/0x30<br /> invoke_syscall+0x44/0x108<br /> el0_svc_common.constprop.0+0xcc/0xf0<br /> do_el0_svc+0x2c/0xb8<br /> el0_svc+0x2c/0x88<br /> el0t_64_sync_handler+0xb8/0xc0<br /> el0t_64_sync+0x18c/0x190<br /> qcom-venus: probe of aa00000.video-codec failed with error -16<br /> <br /> The fix is re-ordering the code related to OPP core. The OPP core<br /> expects all configuration options to be provided before the OPP<br /> table is added.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64: Init jump labels before parse_early_param()<br /> <br /> On 64-bit, calling jump_label_init() in setup_feature_keys() is too<br /> late because static keys may be used in subroutines of<br /> parse_early_param() which is again subroutine of early_init_devtree().<br /> <br /> For example booting with "threadirqs":<br /> <br /> static_key_enable_cpuslocked(): static key &amp;#39;0xc000000002953260&amp;#39; used before call to jump_label_init()<br /> WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120<br /> ...<br /> NIP static_key_enable_cpuslocked+0xfc/0x120<br /> LR static_key_enable_cpuslocked+0xf8/0x120<br /> Call Trace:<br /> static_key_enable_cpuslocked+0xf8/0x120 (unreliable)<br /> static_key_enable+0x30/0x50<br /> setup_forced_irqthreads+0x28/0x40<br /> do_early_param+0xa0/0x108<br /> parse_args+0x290/0x4e0<br /> parse_early_options+0x48/0x5c<br /> parse_early_param+0x58/0x84<br /> early_init_devtree+0xd4/0x518<br /> early_setup+0xb4/0x214<br /> <br /> So call jump_label_init() just before parse_early_param() in<br /> early_init_devtree().<br /> <br /> [mpe: Add call trace to change log and minor wording edits.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()<br /> <br /> As Dipanjan Das reported, syzkaller<br /> found a f2fs bug as below:<br /> <br /> RIP: 0010:f2fs_new_node_page+0x19ac/0x1fc0 fs/f2fs/node.c:1295<br /> Call Trace:<br /> write_all_xattrs fs/f2fs/xattr.c:487 [inline]<br /> __f2fs_setxattr+0xe76/0x2e10 fs/f2fs/xattr.c:743<br /> f2fs_setxattr+0x233/0xab0 fs/f2fs/xattr.c:790<br /> f2fs_xattr_generic_set+0x133/0x170 fs/f2fs/xattr.c:86<br /> __vfs_setxattr+0x115/0x180 fs/xattr.c:182<br /> __vfs_setxattr_noperm+0x125/0x5f0 fs/xattr.c:216<br /> __vfs_setxattr_locked+0x1cf/0x260 fs/xattr.c:277<br /> vfs_setxattr+0x13f/0x330 fs/xattr.c:303<br /> setxattr+0x146/0x160 fs/xattr.c:611<br /> path_setxattr+0x1a7/0x1d0 fs/xattr.c:630<br /> __do_sys_lsetxattr fs/xattr.c:653 [inline]<br /> __se_sys_lsetxattr fs/xattr.c:649 [inline]<br /> __x64_sys_lsetxattr+0xbd/0x150 fs/xattr.c:649<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> NAT entry and nat bitmap can be inconsistent, e.g. one nid is free<br /> in nat bitmap, and blkaddr in its NAT entry is not NULL_ADDR, it<br /> may trigger BUG_ON() in f2fs_new_node_page(), fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware boot<br /> <br /> It is not yet clear, but it is possible to create a firmware so broken<br /> that it will send a reply message before a FW_READY message (it is not<br /> yet clear if FW_READY will arrive later).<br /> Since the reply_data is allocated only after the FW_READY message, this<br /> will lead to a NULL pointer dereference if not filtered out.<br /> <br /> The issue was reported with IPC4 firmware but the same condition is present<br /> for IPC3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Intel: cnl: Do not process IPC reply before firmware boot<br /> <br /> It is not yet clear, but it is possible to create a firmware so broken<br /> that it will send a reply message before a FW_READY message (it is not<br /> yet clear if FW_READY will arrive later).<br /> Since the reply_data is allocated only after the FW_READY message, this<br /> will lead to a NULL pointer dereference if not filtered out.<br /> <br /> The issue was reported with IPC4 firmware but the same condition is present<br /> for IPC3.