Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: Fix linkwatch use-after-free on disconnect<br /> <br /> usbnet uses the work usbnet_deferred_kevent() to perform tasks which may<br /> sleep. On disconnect, completion of the work was originally awaited in<br /> -&gt;ndo_stop(). But in 2003, that was moved to -&gt;disconnect() by historic<br /> commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock":<br /> <br /> https://git.kernel.org/tglx/history/c/0f138bbfd83c<br /> <br /> The change was made because back then, the kernel&amp;#39;s workqueue<br /> implementation did not allow waiting for a single work. One had to wait<br /> for completion of *all* work by calling flush_scheduled_work(), and that<br /> could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex<br /> held in -&gt;ndo_stop().<br /> <br /> The commit solved one problem but created another: It causes a<br /> use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c,<br /> ax88179_178a.c, ch9200.c and smsc75xx.c:<br /> <br /> * If the drivers receive a link change interrupt immediately before<br /> disconnect, they raise EVENT_LINK_RESET in their (non-sleepable)<br /> -&gt;status() callback and schedule usbnet_deferred_kevent().<br /> * usbnet_deferred_kevent() invokes the driver&amp;#39;s -&gt;link_reset() callback,<br /> which calls netif_carrier_{on,off}().<br /> * That in turn schedules the work linkwatch_event().<br /> <br /> Because usbnet_deferred_kevent() is awaited after unregister_netdev(),<br /> netif_carrier_{on,off}() may operate on an unregistered netdev and<br /> linkwatch_event() may run after free_netdev(), causing a use-after-free.<br /> <br /> In 2010, usbnet was changed to only wait for a single instance of<br /> usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf<br /> ("drivers/net: don&amp;#39;t use flush_scheduled_work()").<br /> <br /> Unfortunately the commit neglected to move the wait back to<br /> -&gt;ndo_stop(). Rectify that omission at long last.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix KASAN use-after-free Read in compute_effective_progs<br /> <br /> Syzbot found a Use After Free bug in compute_effective_progs().<br /> The reproducer creates a number of BPF links, and causes a fault<br /> injected alloc to fail, while calling bpf_link_detach on them.<br /> Link detach triggers the link to be freed by bpf_link_free(),<br /> which calls __cgroup_bpf_detach() and update_effective_progs().<br /> If the memory allocation in this function fails, the function restores<br /> the pointer to the bpf_cgroup_link on the cgroup list, but the memory<br /> gets freed just after it returns. After this, every subsequent call to<br /> update_effective_progs() causes this already deallocated pointer to be<br /> dereferenced in prog_list_length(), and triggers KASAN UAF error.<br /> <br /> To fix this issue don&amp;#39;t preserve the pointer to the prog or link in the<br /> list, but remove it and replace it with a dummy prog without shrinking<br /> the table. The subsequent call to __cgroup_bpf_detach() or<br /> __cgroup_bpf_detach() will correct it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: isl29028: Fix the warning in isl29028_remove()<br /> <br /> The driver use the non-managed form of the register function in<br /> isl29028_remove(). To keep the release order as mirroring the ordering<br /> in probe, the driver should use non-managed form in probe, too.<br /> <br /> The following log reveals it:<br /> <br /> [ 32.374955] isl29028 0-0010: remove<br /> [ 32.376861] general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI<br /> [ 32.377676] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]<br /> [ 32.379432] RIP: 0010:kernfs_find_and_get_ns+0x28/0xe0<br /> [ 32.385461] Call Trace:<br /> [ 32.385807] sysfs_unmerge_group+0x59/0x110<br /> [ 32.386110] dpm_sysfs_remove+0x58/0xc0<br /> [ 32.386391] device_del+0x296/0xe50<br /> [ 32.386959] cdev_device_del+0x1d/0xd0<br /> [ 32.387231] devm_iio_device_unreg+0x27/0xb0<br /> [ 32.387542] devres_release_group+0x319/0x3d0<br /> [ 32.388162] i2c_device_remove+0x93/0x1f0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: write inode in fuse_release()<br /> <br /> A race between write(2) and close(2) allows pages to be dirtied after<br /> fuse_flush -&gt; write_inode_now(). If these pages are not flushed from<br /> fuse_release(), then there might not be a writable open file later. So any<br /> remaining dirty pages must be written back before the file is released.<br /> <br /> This is a partial revert of the blamed commit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sg: Allow waiting for commands to complete on removed device<br /> <br /> When a SCSI device is removed while in active use, currently sg will<br /> immediately return -ENODEV on any attempt to wait for active commands that<br /> were sent before the removal. This is problematic for commands that use<br /> SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel<br /> when userspace frees or reuses it after getting ENODEV, leading to<br /> corrupted userspace memory (in the case of READ-type commands) or corrupted<br /> data being sent to the device (in the case of WRITE-type commands). This<br /> has been seen in practice when logging out of a iscsi_tcp session, where<br /> the iSCSI driver may still be processing commands after the device has been<br /> marked for removal.<br /> <br /> Change the policy to allow userspace to wait for active sg commands even<br /> when the device is being removed. Return -ENODEV only when there are no<br /> more responses to read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: Clear the connection field properly<br /> <br /> coresight devices track their connections (output connections) and<br /> hold a reference to the fwnode. When a device goes away, we walk through<br /> the devices on the coresight bus and make sure that the references<br /> are dropped. This happens both ways:<br /> a) For all output connections from the device, drop the reference to<br /> the target device via coresight_release_platform_data()<br /> <br /> b) Iterate over all the devices on the coresight bus and drop the<br /> reference to fwnode if *this* device is the target of the output<br /> connection, via coresight_remove_conns()-&gt;coresight_remove_match().<br /> <br /> However, the coresight_remove_match() doesn&amp;#39;t clear the fwnode field,<br /> after dropping the reference, this causes use-after-free and<br /> additional refcount drops on the fwnode.<br /> <br /> e.g., if we have two devices, A and B, with a connection, A -&gt; B.<br /> If we remove B first, B would clear the reference on B, from A<br /> via coresight_remove_match(). But when A is removed, it still has<br /> a connection with fwnode still pointing to B. Thus it tries to drops<br /> the reference in coresight_release_platform_data(), raising the bells<br /> like :<br /> <br /> [ 91.990153] ------------[ cut here ]------------<br /> [ 91.990163] refcount_t: addition on 0; use-after-free.<br /> [ 91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144<br /> [ 91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-)<br /> crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug]<br /> [ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53<br /> [ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019<br /> [ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 91.990454] pc : refcount_warn_saturate+0xa0/0x144<br /> [ 91.990476] lr : refcount_warn_saturate+0xa0/0x144<br /> [ 91.990496] sp : ffff80000c843640<br /> [ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8<br /> [ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8<br /> [ 91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2<br /> [ 91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40<br /> [ 91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0<br /> [ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375<br /> [ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28<br /> [ 91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572<br /> [ 91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027<br /> [ 91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00<br /> [ 91.991000] Call trace:<br /> [ 91.991012] refcount_warn_saturate+0xa0/0x144<br /> [ 91.991034] kobject_get+0xac/0xb0<br /> [ 91.991055] of_node_get+0x2c/0x40<br /> [ 91.991076] of_fwnode_get+0x40/0x60<br /> [ 91.991094] fwnode_handle_get+0x3c/0x60<br /> [ 91.991116] fwnode_get_nth_parent+0xf4/0x110<br /> [ 91.991137] fwnode_full_name_string+0x48/0xc0<br /> [ 91.991158] device_node_string+0x41c/0x530<br /> [ 91.991178] pointer+0x320/0x3ec<br /> [ 91.991198] vsnprintf+0x23c/0x750<br /> [ 91.991217] vprintk_store+0x104/0x4b0<br /> [ 91.991238] vprintk_emit+0x8c/0x360<br /> [ 91.991257] vprintk_default+0x44/0x50<br /> [ 91.991276] vprintk+0xcc/0xf0<br /> [ 91.991295] _printk+0x68/0x90<br /> [ 91.991315] of_node_release+0x13c/0x14c<br /> [ 91.991334] kobject_put+0x98/0x114<br /> [ 91.991354] of_node_put+0x24/0x34<br /> [ 91.991372] of_fwnode_put+0x40/0x5c<br /> [ 91.991390] fwnode_handle_put+0x38/0x50<br /> [ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight]<br /> [ 91.991472] coresight_unregister+0x64/0xcc [coresight]<br /> [ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x]<br /> [ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x]<br /> [ 91.991598] amba_remove+0x3c/0x19c<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: do not allow SET_ID to refer to another table<br /> <br /> When doing lookups for sets on the same batch by using its ID, a set from a<br /> different table can be used.<br /> <br /> Then, when the table is removed, a reference to the set may be kept after<br /> the set is freed, leading to a potential use-after-free.<br /> <br /> When looking for sets by ID, use the table that was used for the lookup by<br /> name, and only return sets belonging to that same table.<br /> <br /> This fixes CVE-2022-2586, also reported as ZDI-CAN-17470.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: do not allow CHAIN_ID to refer to another table<br /> <br /> When doing lookups for chains on the same batch by using its ID, a chain<br /> from a different table can be used. If a rule is added to a table but<br /> refers to a chain in a different table, it will be linked to the chain in<br /> table2, but would have expressions referring to objects in table1.<br /> <br /> Then, when table1 is removed, the rule will not be removed as its linked to<br /> a chain in table2. When expressions in the rule are processed or removed,<br /> that will lead to a use-after-free.<br /> <br /> When looking for chains by ID, use the table that was used for the lookup<br /> by name, and only return chains belonging to that same table.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: bcm: Fix refcount leak in bcm_kona_smc_init<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: fix oops in concurrently setting insn_emulation sysctls<br /> <br /> emulation_proc_handler() changes table-&gt;data for proc_dointvec_minmax<br /> and can generate the following Oops if called concurrently with itself:<br /> <br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> | Internal error: Oops: 96000006 [#1] SMP<br /> | Call trace:<br /> | update_insn_emulation_mode+0xc0/0x148<br /> | emulation_proc_handler+0x64/0xb8<br /> | proc_sys_call_handler+0x9c/0xf8<br /> | proc_sys_write+0x18/0x20<br /> | __vfs_write+0x20/0x48<br /> | vfs_write+0xe4/0x1d0<br /> | ksys_write+0x70/0xf8<br /> | __arm64_sys_write+0x20/0x28<br /> | el0_svc_common.constprop.0+0x7c/0x1c0<br /> | el0_svc_handler+0x2c/0xa0<br /> | el0_svc+0x8/0x200<br /> <br /> To fix this issue, keep the table-&gt;data as &amp;insn-&gt;current_mode and<br /> use container_of() to retrieve the insn pointer. Another mutex is<br /> used to protect against the current_mode update but not for retrieving<br /> insn_emulation as table-&gt;data is no longer changing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext2: Add more validity checks for inode counts<br /> <br /> Add checks verifying number of inodes stored in the superblock matches<br /> the number computed from number of inodes per group. Also verify we have<br /> at least one block worth of inodes per group. This prevents crashes on<br /> corrupted filesystems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: OMAP2+: pdata-quirks: Fix refcount leak bug<br /> <br /> In pdata_quirks_init_clocks(), the loop contains<br /> of_find_node_by_name() but without corresponding of_node_put().