Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> module: fix [e_shstrndx].sh_size=0 OOB access<br /> <br /> It is trivial to craft a module to trigger OOB access in this line:<br /> <br /> if (info-&gt;secstrings[strhdr-&gt;sh_size - 1] != &amp;#39;\0&amp;#39;) {<br /> <br /> BUG: unable to handle page fault for address: ffffc90000aa0fff<br /> PGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014<br /> RIP: 0010:load_module+0x19b/0x2391<br /> <br /> [rebased patch onto modules-next]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources()<br /> <br /> It will cause null-ptr-deref when using &amp;#39;res&amp;#39;, if platform_get_resource()<br /> returns NULL, so move using &amp;#39;res&amp;#39; after devm_ioremap_resource() that<br /> will check it to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu-v3-sva: Fix mm use-after-free<br /> <br /> We currently call arm64_mm_context_put() without holding a reference to<br /> the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to<br /> ensure the mm only gets freed after we unpinned the ASID.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/mediatek: Remove clk_disable in mtk_iommu_remove<br /> <br /> After the commit b34ea31fe013 ("iommu/mediatek: Always enable the clk on<br /> resume"), the iommu clock is controlled by the runtime callback.<br /> thus remove the clk control in the mtk_iommu_remove.<br /> <br /> Otherwise, it will warning like:<br /> <br /> echo 14018000.iommu &gt; /sys/bus/platform/drivers/mtk-iommu/unbind<br /> <br /> [ 51.413044] ------------[ cut here ]------------<br /> [ 51.413648] vpp0_smi_iommu already disabled<br /> [ 51.414233] WARNING: CPU: 2 PID: 157 at */v5.15-rc1/kernel/mediatek/<br /> drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8<br /> [ 51.417174] Hardware name: MT8195V/C(ENG) (DT)<br /> [ 51.418635] pc : clk_core_disable+0xb0/0xb8<br /> [ 51.419177] lr : clk_core_disable+0xb0/0xb8<br /> ...<br /> [ 51.429375] Call trace:<br /> [ 51.429694] clk_core_disable+0xb0/0xb8<br /> [ 51.430193] clk_core_disable_lock+0x24/0x40<br /> [ 51.430745] clk_disable+0x20/0x30<br /> [ 51.431189] mtk_iommu_remove+0x58/0x118<br /> [ 51.431705] platform_remove+0x28/0x60<br /> [ 51.432197] device_release_driver_internal+0x110/0x1f0<br /> [ 51.432873] device_driver_detach+0x18/0x28<br /> [ 51.433418] unbind_store+0xd4/0x108<br /> [ 51.433886] drv_attr_store+0x24/0x38<br /> [ 51.434363] sysfs_kf_write+0x40/0x58<br /> [ 51.434843] kernfs_fop_write_iter+0x164/0x1e0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on inline_dots inode<br /> <br /> As Wenqing reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=215765<br /> <br /> It will cause a kernel panic with steps:<br /> - mkdir mnt<br /> - mount tmp40.img mnt<br /> - ls mnt<br /> <br /> folio_mark_dirty+0x33/0x50<br /> f2fs_add_regular_entry+0x541/0xad0 [f2fs]<br /> f2fs_add_dentry+0x6c/0xb0 [f2fs]<br /> f2fs_do_add_link+0x182/0x230 [f2fs]<br /> __recover_dot_dentries+0x2d6/0x470 [f2fs]<br /> f2fs_lookup+0x5af/0x6a0 [f2fs]<br /> __lookup_slow+0xac/0x200<br /> lookup_slow+0x45/0x70<br /> walk_component+0x16c/0x250<br /> path_lookupat+0x8b/0x1f0<br /> filename_lookup+0xef/0x250<br /> user_path_at_empty+0x46/0x70<br /> vfs_statx+0x98/0x190<br /> __do_sys_newlstat+0x41/0x90<br /> __x64_sys_newlstat+0x1a/0x30<br /> do_syscall_64+0x37/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root cause is for special file: e.g. character, block, fifo or<br /> socket file, f2fs doesn&amp;#39;t assign address space operations pointer array<br /> for mapping-&gt;a_ops field, so, in a fuzzed image, if inline_dots flag was<br /> tagged in special file, during lookup(), when f2fs runs into<br /> __recover_dot_dentries(), it will cause NULL pointer access once<br /> f2fs_add_regular_entry() calls a_ops-&gt;set_dirty_page().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hfi1: Prevent panic when SDMA is disabled<br /> <br /> If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to<br /> hfi1_write_iter() will dereference a NULL pointer and panic. A typical<br /> stack frame is:<br /> <br /> sdma_select_user_engine [hfi1]<br /> hfi1_user_sdma_process_request [hfi1]<br /> hfi1_write_iter [hfi1]<br /> do_iter_readv_writev<br /> do_iter_write<br /> vfs_writev<br /> do_writev<br /> do_syscall_64<br /> <br /> The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with<br /> EINVAL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: gpio-keys - cancel delayed work only in case of GPIO<br /> <br /> gpio_keys module can either accept gpios or interrupts. The module<br /> initializes delayed work in case of gpios only and is only used if<br /> debounce timer is not used, so make sure cancel_delayed_work_sync()<br /> is called only when its gpio-backed and debounce_use_hrtimer is false.<br /> <br /> This fixes the issue seen below when the gpio_keys module is unloaded and<br /> an interrupt pin is used instead of GPIO:<br /> <br /> [ 360.297569] ------------[ cut here ]------------<br /> [ 360.302303] WARNING: CPU: 0 PID: 237 at kernel/workqueue.c:3066 __flush_work+0x414/0x470<br /> [ 360.310531] Modules linked in: gpio_keys(-)<br /> [ 360.314797] CPU: 0 PID: 237 Comm: rmmod Not tainted 5.18.0-rc5-arm64-renesas-00116-g73636105874d-dirty #166<br /> [ 360.324662] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT)<br /> [ 360.331270] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 360.338318] pc : __flush_work+0x414/0x470<br /> [ 360.342385] lr : __cancel_work_timer+0x140/0x1b0<br /> [ 360.347065] sp : ffff80000a7fba00<br /> [ 360.350423] x29: ffff80000a7fba00 x28: ffff000012b9c5c0 x27: 0000000000000000<br /> [ 360.357664] x26: ffff80000a7fbb80 x25: ffff80000954d0a8 x24: 0000000000000001<br /> [ 360.364904] x23: ffff800009757000 x22: 0000000000000000 x21: ffff80000919b000<br /> [ 360.372143] x20: ffff00000f5974e0 x19: ffff00000f5974e0 x18: ffff8000097fcf48<br /> [ 360.379382] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000053f40<br /> [ 360.386622] x14: ffff800009850e88 x13: 0000000000000002 x12: 000000000000a60c<br /> [ 360.393861] x11: 000000000000a610 x10: 0000000000000000 x9 : 0000000000000008<br /> [ 360.401100] x8 : 0101010101010101 x7 : 00000000a473c394 x6 : 0080808080808080<br /> [ 360.408339] x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffff80000919b458<br /> [ 360.415578] x2 : ffff8000097577f0 x1 : 0000000000000001 x0 : 0000000000000000<br /> [ 360.422818] Call trace:<br /> [ 360.425299] __flush_work+0x414/0x470<br /> [ 360.429012] __cancel_work_timer+0x140/0x1b0<br /> [ 360.433340] cancel_delayed_work_sync+0x10/0x18<br /> [ 360.437931] gpio_keys_quiesce_key+0x28/0x58 [gpio_keys]<br /> [ 360.443327] devm_action_release+0x10/0x18<br /> [ 360.447481] release_nodes+0x8c/0x1a0<br /> [ 360.451194] devres_release_all+0x90/0x100<br /> [ 360.455346] device_unbind_cleanup+0x14/0x60<br /> [ 360.459677] device_release_driver_internal+0xe8/0x168<br /> [ 360.464883] driver_detach+0x4c/0x90<br /> [ 360.468509] bus_remove_driver+0x54/0xb0<br /> [ 360.472485] driver_unregister+0x2c/0x58<br /> [ 360.476462] platform_driver_unregister+0x10/0x18<br /> [ 360.481230] gpio_keys_exit+0x14/0x828 [gpio_keys]<br /> [ 360.486088] __arm64_sys_delete_module+0x1e0/0x270<br /> [ 360.490945] invoke_syscall+0x40/0xf8<br /> [ 360.494661] el0_svc_common.constprop.3+0xf0/0x110<br /> [ 360.499515] do_el0_svc+0x20/0x78<br /> [ 360.502877] el0_svc+0x48/0xf8<br /> [ 360.505977] el0t_64_sync_handler+0x88/0xb0<br /> [ 360.510216] el0t_64_sync+0x148/0x14c<br /> [ 360.513930] irq event stamp: 4306<br /> [ 360.517288] hardirqs last enabled at (4305): [] __cancel_work_timer+0x130/0x1b0<br /> [ 360.526359] hardirqs last disabled at (4306): [] el1_dbg+0x24/0x88<br /> [ 360.534204] softirqs last enabled at (4278): [] _stext+0x4a0/0x5e0<br /> [ 360.542133] softirqs last disabled at (4267): [] irq_exit_rcu+0x18c/0x1b0<br /> [ 360.550591] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/iommu: Add missing of_node_put in iommu_init_early_dart<br /> <br /> The device_node pointer is returned by of_find_compatible_node<br /> with refcount incremented. We should use of_node_put() to avoid<br /> the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/xics: fix refcount leak in icp_opal_init()<br /> <br /> The of_find_compatible_node() function returns a node pointer with<br /> refcount incremented, use of_node_put() on it when done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hfi1: Prevent use of lock before it is initialized<br /> <br /> If there is a failure during probe of hfi1 before the sdma_map_lock is<br /> initialized, the call to hfi1_free_devdata() will attempt to use a lock<br /> that has not been initialized. If the locking correctness validator is on<br /> then an INFO message and stack trace resembling the following may be seen:<br /> <br /> INFO: trying to register non-static key.<br /> The code is fine but needs lockdep annotation, or maybe<br /> you didn&amp;#39;t initialize this object before use?<br /> turning off the locking correctness validator.<br /> Call Trace:<br /> register_lock_class+0x11b/0x880<br /> __lock_acquire+0xf3/0x7930<br /> lock_acquire+0xff/0x2d0<br /> _raw_spin_lock_irq+0x46/0x60<br /> sdma_clean+0x42a/0x660 [hfi1]<br /> hfi1_free_devdata+0x3a7/0x420 [hfi1]<br /> init_one+0x867/0x11a0 [hfi1]<br /> pci_device_probe+0x40e/0x8d0<br /> <br /> The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map<br /> memory, and sdma_map is not allocated/initialized until after<br /> sdma_map_lock has been initialized. This code only needs to be run if<br /> sdma_map is not NULL, and so checking for that condition will avoid trying<br /> to use the lock before it is initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store()<br /> <br /> The sysfs sriov_numvfs_store() path acquires the device lock before the<br /> config space access lock:<br /> <br /> sriov_numvfs_store<br /> device_lock # A (1) acquire device lock<br /> sriov_configure<br /> vfio_pci_sriov_configure # (for example)<br /> vfio_pci_core_sriov_configure<br /> pci_disable_sriov<br /> sriov_disable<br /> pci_cfg_access_lock<br /> pci_wait_cfg # B (4) wait for dev-&gt;block_cfg_access == 0<br /> <br /> Previously, pci_dev_lock() acquired the config space access lock before the<br /> device lock:<br /> <br /> pci_dev_lock<br /> pci_cfg_access_lock<br /> dev-&gt;block_cfg_access = 1 # B (2) set dev-&gt;block_cfg_access = 1<br /> device_lock # A (3) wait for device lock<br /> <br /> Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may<br /> deadlock with sriov_numvfs_store() if the operations occur in the sequence<br /> (1) (2) (3) (4).<br /> <br /> Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires<br /> the device lock before the config space access lock, the same as the<br /> sriov_numvfs_store() path.<br /> <br /> [bhelgaas: combined and adapted commit log from Jay Zhou&amp;#39;s independent<br /> subsequent posting:<br /> https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: davinci_voicecodec: Fix possible null-ptr-deref davinci_vc_probe()<br /> <br /> It will cause null-ptr-deref when using &amp;#39;res&amp;#39;, if platform_get_resource()<br /> returns NULL, so move using &amp;#39;res&amp;#39; after devm_ioremap_resource() that<br /> will check it to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.