Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: ubi_create_volume: Fix use-after-free when volume creation failed<br /> <br /> There is an use-after-free problem for &amp;#39;eba_tbl&amp;#39; in ubi_create_volume()&amp;#39;s<br /> error handling path:<br /> <br /> ubi_eba_replace_table(vol, eba_tbl)<br /> vol-&gt;eba_tbl = tbl<br /> out_mapping:<br /> ubi_eba_destroy_table(eba_tbl) // Free &amp;#39;eba_tbl&amp;#39;<br /> out_unlock:<br /> put_device(&amp;vol-&gt;dev)<br /> vol_release<br /> kfree(tbl-&gt;entries) // UAF<br /> <br /> Fix it by removing redundant &amp;#39;eba_tbl&amp;#39; releasing.<br /> Fetch a reproducer in [Link].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: usbip: fix a refcount leak in stub_probe()<br /> <br /> usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails<br /> after that, usb_put_dev() needs to be called to release the reference.<br /> <br /> Fix this by moving usb_put_dev() to sdev_free error path handling.<br /> <br /> Find this by code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macsec: fix UAF bug for real_dev<br /> <br /> Create a new macsec device but not get reference to real_dev. That can<br /> not ensure that real_dev is freed after macsec. That will trigger the<br /> UAF bug for real_dev as following:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662<br /> Call Trace:<br /> ...<br /> macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662<br /> dev_get_iflink+0x73/0xe0 net/core/dev.c:637<br /> default_operstate net/core/link_watch.c:42 [inline]<br /> rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54<br /> linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161<br /> <br /> Allocated by task 22209:<br /> ...<br /> alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549<br /> rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235<br /> veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748<br /> <br /> Freed by task 8:<br /> ...<br /> kfree+0xd6/0x4d0 mm/slub.c:4552<br /> kvfree+0x42/0x50 mm/util.c:615<br /> device_release+0x9f/0x240 drivers/base/core.c:2229<br /> kobject_cleanup lib/kobject.c:673 [inline]<br /> kobject_release lib/kobject.c:704 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> kobject_put+0x1c8/0x540 lib/kobject.c:721<br /> netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327<br /> <br /> After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")<br /> and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we<br /> can add dev_hold_track() in macsec_dev_init() and dev_put_track() in<br /> macsec_free_netdev() to fix the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: mtk_scp: Fix a potential double free<br /> <br /> &amp;#39;scp-&gt;rproc&amp;#39; is allocated using devm_rproc_alloc(), so there is no need<br /> to free it explicitly in the remove function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250_aspeed_vuart: Fix potential NULL dereference in aspeed_vuart_probe<br /> <br /> platform_get_resource() may fail and return NULL, so we should<br /> better check it&amp;#39;s return value to avoid a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix list iterator in fastrpc_req_mem_unmap_impl<br /> <br /> This is another instance of incorrect use of list iterator and<br /> checking it for NULL.<br /> <br /> The list iterator value &amp;#39;map&amp;#39; will *always* be set and non-NULL<br /> by list_for_each_entry(), so it is incorrect to assume that the<br /> iterator value will be NULL if the list is empty (in this case, the<br /> check &amp;#39;if (!map) {&amp;#39; will always be false and never exit as expected).<br /> <br /> To fix the bug, use a new variable &amp;#39;iter&amp;#39; as the list iterator,<br /> while use the original variable &amp;#39;map&amp;#39; as a dedicated pointer to<br /> point to the found element.<br /> <br /> Without this patch, Kernel crashes with below trace:<br /> <br /> Unable to handle kernel access to user memory outside uaccess routines<br /> at virtual address 0000ffff7fb03750<br /> ...<br /> Call trace:<br /> fastrpc_map_create+0x70/0x290 [fastrpc]<br /> fastrpc_req_mem_map+0xf0/0x2dc [fastrpc]<br /> fastrpc_device_ioctl+0x138/0xc60 [fastrpc]<br /> __arm64_sys_ioctl+0xa8/0xec<br /> invoke_syscall+0x48/0x114<br /> el0_svc_common.constprop.0+0xd4/0xfc<br /> do_el0_svc+0x28/0x90<br /> el0_svc+0x3c/0x130<br /> el0t_64_sync_handler+0xa4/0x130<br /> el0t_64_sync+0x18c/0x190<br /> Code: 14000016 f94000a5 eb05029f 54000260 (b94018a6)<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-iolatency: Fix inflight count imbalances and IO hangs on offline<br /> <br /> iolatency needs to track the number of inflight IOs per cgroup. As this<br /> tracking can be expensive, it is disabled when no cgroup has iolatency<br /> configured for the device. To ensure that the inflight counters stay<br /> balanced, iolatency_set_limit() freezes the request_queue while manipulating<br /> the enabled counter, which ensures that no IO is in flight and thus all<br /> counters are zero.<br /> <br /> Unfortunately, iolatency_set_limit() isn&amp;#39;t the only place where the enabled<br /> counter is manipulated. iolatency_pd_offline() can also dec the counter and<br /> trigger disabling. As this disabling happens without freezing the q, this<br /> can easily happen while some IOs are in flight and thus leak the counts.<br /> <br /> This can be easily demonstrated by turning on iolatency on an one empty<br /> cgroup while IOs are in flight in other cgroups and then removing the<br /> cgroup. Note that iolatency shouldn&amp;#39;t have been enabled elsewhere in the<br /> system to ensure that removing the cgroup disables iolatency for the whole<br /> device.<br /> <br /> The following keeps flipping on and off iolatency on sda:<br /> <br /> echo +io &gt; /sys/fs/cgroup/cgroup.subtree_control<br /> while true; do<br /> mkdir -p /sys/fs/cgroup/test<br /> echo &amp;#39;8:0 target=100000&amp;#39; &gt; /sys/fs/cgroup/test/io.latency<br /> sleep 1<br /> rmdir /sys/fs/cgroup/test<br /> sleep 1<br /> done<br /> <br /> and there&amp;#39;s concurrent fio generating direct rand reads:<br /> <br /> fio --name test --filename=/dev/sda --direct=1 --rw=randread \<br /> --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k<br /> <br /> while monitoring with the following drgn script:<br /> <br /> while True:<br /> for css in css_for_each_descendant_pre(prog[&amp;#39;blkcg_root&amp;#39;].css.address_of_()):<br /> for pos in hlist_for_each(container_of(css, &amp;#39;struct blkcg&amp;#39;, &amp;#39;css&amp;#39;).blkg_list):<br /> blkg = container_of(pos, &amp;#39;struct blkcg_gq&amp;#39;, &amp;#39;blkcg_node&amp;#39;)<br /> pd = blkg.pd[prog[&amp;#39;blkcg_policy_iolatency&amp;#39;].plid]<br /> if pd.value_() == 0:<br /> continue<br /> iolat = container_of(pd, &amp;#39;struct iolatency_grp&amp;#39;, &amp;#39;pd&amp;#39;)<br /> inflight = iolat.rq_wait.inflight.counter.value_()<br /> if inflight:<br /> print(f&amp;#39;inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} &amp;#39;<br /> f&amp;#39;{cgroup_path(css.cgroup).decode("utf-8")}&amp;#39;)<br /> time.sleep(1)<br /> <br /> The monitoring output looks like the following:<br /> <br /> inflight=1 sda /user.slice<br /> inflight=1 sda /user.slice<br /> ...<br /> inflight=14 sda /user.slice<br /> inflight=13 sda /user.slice<br /> inflight=17 sda /user.slice<br /> inflight=15 sda /user.slice<br /> inflight=18 sda /user.slice<br /> inflight=17 sda /user.slice<br /> inflight=20 sda /user.slice<br /> inflight=19 sda /user.slice

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: check attribute length for bearer name<br /> <br /> syzbot reported uninit-value:<br /> =====================================================<br /> BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]<br /> BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725<br /> string_nocheck lib/vsprintf.c:644 [inline]<br /> string+0x4f9/0x6f0 lib/vsprintf.c:725<br /> vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806<br /> vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158<br /> vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256<br /> vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283<br /> vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50<br /> _printk+0x18d/0x1cf kernel/printk/printk.c:2293<br /> tipc_enable_bearer net/tipc/bearer.c:371 [inline]<br /> __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033<br /> tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]<br /> <br /> - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.<br /> - Do not use &amp;#39;illegal name&amp;#39; in printing message.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtc: mt6397: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref if platform_get_resource() returns NULL,<br /> we need check the return value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sd: Fix potential NULL pointer dereference<br /> <br /> If sd_probe() sees an early error before sdkp-&gt;device is initialized,<br /> sd_zbc_release_disk() is called. This causes a NULL pointer dereference<br /> when sd_is_zoned() is called inside that function. Avoid this by removing<br /> the call to sd_zbc_release_disk() in sd_probe() error path.<br /> <br /> This change is safe and does not result in zone information memory leakage<br /> because the zone information for a zoned disk is allocated only when<br /> sd_revalidate_disk() is called, at which point sdkp-&gt;disk_dev is fully set,<br /> resulting in sd_disk_release() being called when needed to cleanup a disk<br /> zone information using sd_zbc_release_disk().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: don&amp;#39;t touch -&gt;tagset in blk_mq_get_sq_hctx<br /> <br /> blk_mq_run_hw_queues() could be run when there isn&amp;#39;t queued request and<br /> after queue is cleaned up, at that time tagset is freed, because tagset<br /> lifetime is covered by driver, and often freed after blk_cleanup_queue()<br /> returns.<br /> <br /> So don&amp;#39;t touch -&gt;tagset for figuring out current default hctx by the mapping<br /> built in request queue, so use-after-free on tagset can be avoided. Meantime<br /> this way should be fast than retrieving mapping from tagset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sfc: fix considering that all channels have TX queues<br /> <br /> Normally, all channels have RX and TX queues, but this is not true if<br /> modparam efx_separate_tx_channels=1 is used. In that cases, some<br /> channels only have RX queues and others only TX queues (or more<br /> preciselly, they have them allocated, but not initialized).<br /> <br /> Fix efx_channel_has_tx_queues to return the correct value for this case<br /> too.<br /> <br /> Messages shown at probe time before the fix:<br /> sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0<br /> ------------[ cut here ]------------<br /> netdevice: ens6f0np0: failed to initialise TXQ -1<br /> WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc]<br /> [...] stripped<br /> RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc]<br /> [...] stripped<br /> Call Trace:<br /> efx_init_tx_queue+0xaa/0xf0 [sfc]<br /> efx_start_channels+0x49/0x120 [sfc]<br /> efx_start_all+0x1f8/0x430 [sfc]<br /> efx_net_open+0x5a/0xe0 [sfc]<br /> __dev_open+0xd0/0x190<br /> __dev_change_flags+0x1b3/0x220<br /> dev_change_flags+0x21/0x60<br /> [...] stripped<br /> <br /> Messages shown at remove time before the fix:<br /> sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues<br /> sfc 0000:03:00.0 ens6f0np0: failed to flush queues