Vulnerabilities

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 /> 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.

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 /> wifi: mac80211: fix use-after-free in chanctx code<br /> <br /> In ieee80211_vif_use_reserved_context(), when we have an<br /> old context and the new context&amp;#39;s replace_state is set to<br /> IEEE80211_CHANCTX_REPLACE_NONE, we free the old context<br /> in ieee80211_vif_use_reserved_reassign(). Therefore, we<br /> cannot check the old_ctx anymore, so we should set it to<br /> NULL after this point.<br /> <br /> However, since the new_ctx replace state is clearly not<br /> IEEE80211_CHANCTX_REPLACES_OTHER, we&amp;#39;re not going to do<br /> anything else in this function and can just return to<br /> avoid accessing the freed old_ctx.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iwlwifi: mei: fix potential NULL-ptr deref<br /> <br /> If SKB allocation fails, continue rather than using the NULL<br /> pointer.<br /> <br /> Coverity CID: 1497650

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: Fix free of uninitialized nfs4_label on referral lookup.<br /> <br /> Send along the already-allocated fattr along with nfs4_fs_locations, and<br /> drop the memcpy of fattr. We end up growing two more allocations, but this<br /> fixes up a crash as:<br /> <br /> PID: 790 TASK: ffff88811b43c000 CPU: 0 COMMAND: "ls"<br /> #0 [ffffc90000857920] panic at ffffffff81b9bfde<br /> #1 [ffffc900008579c0] do_trap at ffffffff81023a9b<br /> #2 [ffffc90000857a10] do_error_trap at ffffffff81023b78<br /> #3 [ffffc90000857a58] exc_stack_segment at ffffffff81be1f45<br /> #4 [ffffc90000857a80] asm_exc_stack_segment at ffffffff81c009de<br /> #5 [ffffc90000857b08] nfs_lookup at ffffffffa0302322 [nfs]<br /> #6 [ffffc90000857b70] __lookup_slow at ffffffff813a4a5f<br /> #7 [ffffc90000857c60] walk_component at ffffffff813a86c4<br /> #8 [ffffc90000857cb8] path_lookupat at ffffffff813a9553<br /> #9 [ffffc90000857cf0] filename_lookup at ffffffff813ab86b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup<br /> <br /> Commit b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather<br /> than .remove") fixed a use-after-free error due the vesafb driver freeing<br /> the fb_info in the .remove handler instead of doing it in .fb_destroy.<br /> <br /> This can happen if the .fb_destroy callback is executed after the .remove<br /> callback, since the former tries to access a pointer freed by the latter.<br /> <br /> But that change didn&amp;#39;t take into account that another possible scenario is<br /> that .fb_destroy is called before the .remove callback. For example, if no<br /> process has the fbdev chardev opened by the time the driver is removed.<br /> <br /> If that&amp;#39;s the case, fb_info will be freed when unregister_framebuffer() is<br /> called, making the fb_info pointer accessed in vesafb_remove() after that<br /> to no longer be valid.<br /> <br /> To prevent that, move the expression containing the info-&gt;par to happen<br /> before the unregister_framebuffer() function call.