Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash<br /> <br /> The rehash delayed work migrates filters from one region to another<br /> according to the number of available credits.<br /> <br /> The migrated from region is destroyed at the end of the work if the<br /> number of credits is non-negative as the assumption is that this is<br /> indicative of migration being complete. This assumption is incorrect as<br /> a non-negative number of credits can also be the result of a failed<br /> migration.<br /> <br /> The destruction of a region that still has filters referencing it can<br /> result in a use-after-free [1].<br /> <br /> Fix by not destroying the region if migration failed.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230<br /> Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858<br /> <br /> CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5<br /> Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019<br /> Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xc6/0x120<br /> print_report+0xce/0x670<br /> kasan_report+0xd7/0x110<br /> mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230<br /> mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70<br /> mlxsw_sp_acl_atcam_entry_del+0x81/0x210<br /> mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 174:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> __kmalloc+0x19c/0x360<br /> mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 7:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> poison_slab_object+0x102/0x170<br /> __kasan_slab_free+0x14/0x30<br /> kfree+0xc1/0x290<br /> mlxsw_sp_acl_tcam_region_destroy+0x272/0x310<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update<br /> <br /> The rule activity update delayed work periodically traverses the list of<br /> configured rules and queries their activity from the device.<br /> <br /> As part of this task it accesses the entry pointed by &amp;#39;ventry-&gt;entry&amp;#39;,<br /> but this entry can be changed concurrently by the rehash delayed work,<br /> leading to a use-after-free [1].<br /> <br /> Fix by closing the race and perform the activity query under the<br /> &amp;#39;vregion-&gt;lock&amp;#39; mutex.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140<br /> Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181<br /> <br /> CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2<br /> Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019<br /> Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xc6/0x120<br /> print_report+0xce/0x670<br /> kasan_report+0xd7/0x110<br /> mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140<br /> mlxsw_sp_acl_rule_activity_update_work+0x219/0x400<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 1039:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> __kmalloc+0x19c/0x360<br /> mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0<br /> mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 1039:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> poison_slab_object+0x102/0x170<br /> __kasan_slab_free+0x14/0x30<br /> kfree+0xc1/0x290<br /> mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300<br /> process_one_work+0x8eb/0x19b0<br /> worker_thread+0x6c9/0xf70<br /> kthread+0x2c9/0x3b0<br /> ret_from_fork+0x4d/0x80<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: mediatek: Fix double free of skb in coredump<br /> <br /> hci_devcd_append() would free the skb on error so the caller don&amp;#39;t<br /> have to free it again otherwise it would cause the double free of skb.<br /> <br /> Reported-by : Dan Carpenter

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: bridge: replace physindev with physinif in nf_bridge_info<br /> <br /> An skb can be added to a neigh-&gt;arp_queue while waiting for an arp<br /> reply. Where original skb&amp;#39;s skb-&gt;dev can be different to neigh&amp;#39;s<br /> neigh-&gt;dev. For instance in case of bridging dnated skb from one veth to<br /> another, the skb would be added to a neigh-&gt;arp_queue of the bridge.<br /> <br /> As skb-&gt;dev can be reset back to nf_bridge-&gt;physindev and used, and as<br /> there is no explicit mechanism that prevents this physindev from been<br /> freed under us (for instance neigh_flush_dev doesn&amp;#39;t cleanup skbs from<br /> different device&amp;#39;s neigh queue) we can crash on e.g. this stack:<br /> <br /> arp_process<br /> neigh_update<br /> skb = __skb_dequeue(&amp;neigh-&gt;arp_queue)<br /> neigh_resolve_output(..., skb)<br /> ...<br /> br_nf_dev_xmit<br /> br_nf_pre_routing_finish_bridge_slow<br /> skb-&gt;dev = nf_bridge-&gt;physindev<br /> br_handle_frame_finish<br /> <br /> Let&amp;#39;s use plain ifindex instead of net_device link. To peek into the<br /> original net_device we will use dev_get_by_index_rcu(). Thus either we<br /> get device and are safe to use it or we don&amp;#39;t get it and drop skb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()<br /> <br /> subflow_finish_connect() uses four fields (backup, join_id, thmac, none)<br /> that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set<br /> in mptcp_parse_option()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tls, fix WARNIING in __sk_msg_free<br /> <br /> A splice with MSG_SPLICE_PAGES will cause tls code to use the<br /> tls_sw_sendmsg_splice path in the TLS sendmsg code to move the user<br /> provided pages from the msg into the msg_pl. This will loop over the<br /> msg until msg_pl is full, checked by sk_msg_full(msg_pl). The user<br /> can also set the MORE flag to hint stack to delay sending until receiving<br /> more pages and ideally a full buffer.<br /> <br /> If the user adds more pages to the msg than can fit in the msg_pl<br /> scatterlist (MAX_MSG_FRAGS) we should ignore the MORE flag and send<br /> the buffer anyways.<br /> <br /> What actually happens though is we abort the msg to msg_pl scatterlist<br /> setup and then because we forget to set &amp;#39;full record&amp;#39; indicating we<br /> can no longer consume data without a send we fallthrough to the &amp;#39;continue&amp;#39;<br /> path which will check if msg_data_left(msg) has more bytes to send and<br /> then attempts to fit them in the already full msg_pl. Then next<br /> iteration of sender doing send will encounter a full msg_pl and throw<br /> the warning in the syzbot report.<br /> <br /> To fix simply check if we have a full_record in splice code path and<br /> if not send the msg regardless of MORE flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: sof-common: Add NULL check for normal_link string<br /> <br /> It&amp;#39;s not granted that all entries of struct sof_conn_stream declare<br /> a `normal_link` (a non-SOF, direct link) string, and this is the case<br /> for SoCs that support only SOF paths (hence do not support both direct<br /> and SOF usecases).<br /> <br /> For example, in the case of MT8188 there is no normal_link string in<br /> any of the sof_conn_stream entries and there will be more drivers<br /> doing that in the future.<br /> <br /> To avoid possible NULL pointer KPs, add a NULL check for `normal_link`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Use device rbtree in iopf reporting path<br /> <br /> The existing I/O page fault handler currently locates the PCI device by<br /> calling pci_get_domain_bus_and_slot(). This function searches the list<br /> of all PCI devices until the desired device is found. To improve lookup<br /> efficiency, replace it with device_rbtree_find() to search the device<br /> within the probed device rbtree.<br /> <br /> The I/O page fault is initiated by the device, which does not have any<br /> synchronization mechanism with the software to ensure that the device<br /> stays in the probed device tree. Theoretically, a device could be released<br /> by the IOMMU subsystem after device_rbtree_find() and before<br /> iopf_get_dev_fault_param(), which would cause a use-after-free problem.<br /> <br /> Add a mutex to synchronize the I/O page fault reporting path and the IOMMU<br /> release device path. This lock doesn&amp;#39;t introduce any performance overhead,<br /> as the conflict between I/O page fault reporting and device releasing is<br /> very rare.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: fix reserve_cblocks counting error when out of space<br /> <br /> When a file only needs one direct_node, performing the following<br /> operations will cause the file to be unrepairable:<br /> <br /> unisoc # ./f2fs_io compress test.apk<br /> unisoc #df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 1.2M 100% /data<br /> <br /> unisoc # ./f2fs_io release_cblocks test.apk<br /> 924<br /> unisoc # df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 4.8M 100% /data<br /> <br /> unisoc # dd if=/dev/random of=file4 bs=1M count=3<br /> 3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s<br /> unisoc # df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 1.8M 100% /data<br /> <br /> unisoc # ./f2fs_io reserve_cblocks test.apk<br /> F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device<br /> <br /> adb reboot<br /> unisoc # df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 11M 100% /data<br /> unisoc # ./f2fs_io reserve_cblocks test.apk<br /> 0<br /> <br /> This is because the file has only one direct_node. After returning<br /> to -ENOSPC, reserved_blocks += ret will not be executed. As a result,<br /> the reserved_blocks at this time is still 0, which is not the real<br /> number of reserved blocks. Therefore, fsck cannot be set to repair<br /> the file.<br /> <br /> After this patch, the fsck flag will be set to fix this problem.<br /> <br /> unisoc # df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 1.8M 100% /data<br /> unisoc # ./f2fs_io reserve_cblocks test.apk<br /> F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device<br /> <br /> adb reboot then fsck will be executed<br /> unisoc # df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 11M 100% /data<br /> unisoc # ./f2fs_io reserve_cblocks test.apk<br /> 924

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: dbg-tlv: ensure NUL termination<br /> <br /> The iwl_fw_ini_debug_info_tlv is used as a string, so we must<br /> ensure the string is terminated correctly before using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: zswap: fix shrinker NULL crash with cgroup_disable=memory<br /> <br /> Christian reports a NULL deref in zswap that he bisected down to the zswap<br /> shrinker. The issue also cropped up in the bug trackers of libguestfs [1]<br /> and the Red Hat bugzilla [2].<br /> <br /> The problem is that when memcg is disabled with the boot time flag, the<br /> zswap shrinker might get called with sc-&gt;memcg == NULL. This is okay in<br /> many places, like the lruvec operations. But it crashes in<br /> memcg_page_state() - which is only used due to the non-node accounting of<br /> cgroup&amp;#39;s the zswap memory to begin with.<br /> <br /> Nhat spotted that the memcg can be NULL in the memcg-disabled case, and I<br /> was then able to reproduce the crash locally as well.<br /> <br /> [1] https://github.com/libguestfs/libguestfs/issues/139<br /> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2275252

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic-v3-its: Prevent double free on error<br /> <br /> The error handling path in its_vpe_irq_domain_alloc() causes a double free<br /> when its_vpe_init() fails after successfully allocating at least one<br /> interrupt. This happens because its_vpe_irq_domain_free() frees the<br /> interrupts along with the area bitmap and the vprop_page and<br /> its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the<br /> vprop_page again.<br /> <br /> Fix this by unconditionally invoking its_vpe_irq_domain_free() which<br /> handles all cases correctly and by removing the bitmap/vprop_page freeing<br /> from its_vpe_irq_domain_alloc().<br /> <br /> [ tglx: Massaged change log ]