Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211-hwsim: fix late beacon hrtimer handling<br /> <br /> Thomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx<br /> that our handling of the hrtimer here is wrong: If the timer fires<br /> late (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot)<br /> then it tries to actually rearm the timer at the next deadline,<br /> which might be in the past already:<br /> <br /> 1 2 3 N N+1<br /> | | | ... | |<br /> <br /> ^ intended to fire here (1)<br /> ^ next deadline here (2)<br /> ^ actually fired here<br /> <br /> The next time it fires, it&amp;#39;s later, but will still try to schedule<br /> for the next deadline (now 3), etc. until it catches up with N,<br /> but that might take a long time, causing stalls etc.<br /> <br /> Now, all of this is simulation, so we just have to fix it, but<br /> note that the behaviour is wrong even per spec, since there&amp;#39;s no<br /> value then in sending all those beacons unaligned - they should be<br /> aligned to the TBTT (1, 2, 3, ... in the picture), and if we&amp;#39;re a<br /> bit (or a lot) late, then just resume at that point.<br /> <br /> Therefore, change the code to use hrtimer_forward_now() which will<br /> ensure that the next firing of the timer would be at N+1 (in the<br /> picture), i.e. the next interval point after the current time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nexthop: Fix memory leaks in nexthop notification chain listeners<br /> <br /> syzkaller discovered memory leaks [1] that can be reduced to the<br /> following commands:<br /> <br /> # ip nexthop add id 1 blackhole<br /> # devlink dev reload pci/0000:06:00.0<br /> <br /> As part of the reload flow, mlxsw will unregister its netdevs and then<br /> unregister from the nexthop notification chain. Before unregistering<br /> from the notification chain, mlxsw will receive delete notifications for<br /> nexthop objects using netdevs registered by mlxsw or their uppers. mlxsw<br /> will not receive notifications for nexthops using netdevs that are not<br /> dismantled as part of the reload flow. For example, the blackhole<br /> nexthop above that internally uses the loopback netdev as its nexthop<br /> device.<br /> <br /> One way to fix this problem is to have listeners flush their nexthop<br /> tables after unregistering from the notification chain. This is<br /> error-prone as evident by this patch and also not symmetric with the<br /> registration path where a listener receives a dump of all the existing<br /> nexthops.<br /> <br /> Therefore, fix this problem by replaying delete notifications for the<br /> listener being unregistered. This is symmetric to the registration path<br /> and also consistent with the netdev notification chain.<br /> <br /> The above means that unregister_nexthop_notifier(), like<br /> register_nexthop_notifier(), will have to take RTNL in order to iterate<br /> over the existing nexthops and that any callers of the function cannot<br /> hold RTNL. This is true for mlxsw and netdevsim, but not for the VXLAN<br /> driver. To avoid a deadlock, change the latter to unregister its nexthop<br /> listener without holding RTNL, making it symmetric to the registration<br /> path.<br /> <br /> [1]<br /> unreferenced object 0xffff88806173d600 (size 512):<br /> comm "syz-executor.0", pid 1290, jiffies 4295583142 (age 143.507s)<br /> hex dump (first 32 bytes):<br /> 41 9d 1e 60 80 88 ff ff 08 d6 73 61 80 88 ff ff A..`......sa....<br /> 08 d6 73 61 80 88 ff ff 01 00 00 00 00 00 00 00 ..sa............<br /> backtrace:<br /> [] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]<br /> [] slab_post_alloc_hook+0x96/0x490 mm/slab.h:522<br /> [] slab_alloc_node mm/slub.c:3206 [inline]<br /> [] slab_alloc mm/slub.c:3214 [inline]<br /> [] kmem_cache_alloc_trace+0x163/0x370 mm/slub.c:3231<br /> [] kmalloc include/linux/slab.h:591 [inline]<br /> [] kzalloc include/linux/slab.h:721 [inline]<br /> [] mlxsw_sp_nexthop_obj_group_create drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4918 [inline]<br /> [] mlxsw_sp_nexthop_obj_new drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5054 [inline]<br /> [] mlxsw_sp_nexthop_obj_event+0x59a/0x2910 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5239<br /> [] notifier_call_chain+0xbd/0x210 kernel/notifier.c:83<br /> [] blocking_notifier_call_chain kernel/notifier.c:318 [inline]<br /> [] blocking_notifier_call_chain+0x72/0xa0 kernel/notifier.c:306<br /> [] call_nexthop_notifiers+0x156/0x310 net/ipv4/nexthop.c:244<br /> [] insert_nexthop net/ipv4/nexthop.c:2336 [inline]<br /> [] nexthop_add net/ipv4/nexthop.c:2644 [inline]<br /> [] rtm_new_nexthop+0x14e8/0x4d10 net/ipv4/nexthop.c:2913<br /> [] rtnetlink_rcv_msg+0x448/0xbf0 net/core/rtnetlink.c:5572<br /> [] netlink_rcv_skb+0x173/0x480 net/netlink/af_netlink.c:2504<br /> [] rtnetlink_rcv+0x22/0x30 net/core/rtnetlink.c:5590<br /> [] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]<br /> [] netlink_unicast+0x5ae/0x7f0 net/netlink/af_netlink.c:1340<br /> [] netlink_sendmsg+0x8e1/0xe30 net/netlink/af_netlink.c:1929<br /> [] sock_sendmsg_nosec net/socket.c:704 [inline<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: fix use after free on rmmod<br /> <br /> plat_dev-&gt;dev-&gt;platform_data is released by platform_device_unregister(),<br /> use of pclk and hclk is a use-after-free. Since device unregister won&amp;#39;t<br /> need a clk device we adjust the function call sequence to fix this issue.<br /> <br /> [ 31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci]<br /> [ 31.275563] Freed by task 306:<br /> [ 30.276782] platform_device_release+0x25/0x80

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic-v3-its: Fix potential VPE leak on error<br /> <br /> In its_vpe_irq_domain_alloc, when its_vpe_init() returns an error,<br /> there is an off-by-one in the number of VPEs to be freed.<br /> <br /> Fix it by simply passing the number of VPEs allocated, which is the<br /> index of the loop iterating over the VPEs.<br /> <br /> [maz: fixed commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-debug: prevent an error message from causing runtime problems<br /> <br /> For some drivers, that use the DMA API. This error message can be reached<br /> several millions of times per second, causing spam to the kernel&amp;#39;s printk<br /> buffer and bringing the CPU usage up to 100% (so, it should be rate<br /> limited). However, since there is at least one driver that is in the<br /> mainline and suffers from the error condition, it is more useful to<br /> err_printk() here instead of just rate limiting the error message (in hopes<br /> that it will make it easier for other drivers that suffer from this issue<br /> to be spotted).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blktrace: Fix uaf in blk_trace access after removing by sysfs<br /> <br /> There is an use-after-free problem triggered by following process:<br /> <br /> P1(sda) P2(sdb)<br /> echo 0 &gt; /sys/block/sdb/trace/enable<br /> blk_trace_remove_queue<br /> synchronize_rcu<br /> blk_trace_free<br /> relay_close<br /> rcu_read_lock<br /> __blk_add_trace<br /> trace_note_tsk<br /> (Iterate running_trace_list)<br /> relay_close_buf<br /> relay_destroy_buf<br /> kfree(buf)<br /> trace_note(sdb&amp;#39;s bt)<br /> relay_reserve<br /> buf-&gt;offset /sys/block/sdb/trace/enable &amp;<br /> // Add delay(mdelay/msleep) before kernel enters blk_trace_free()<br /> <br /> ioctl$SG_IO(/dev/sda, SG_IO, ...)<br /> // Enters trace_note_tsk() after blk_trace_free() returned<br /> // Use mdelay in rcu region rather than msleep(which may schedule out)<br /> <br /> Remove blk_trace from running_list before calling blk_trace_free() by<br /> sysfs if blk_trace is at Blktrace_running state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add oversize check before call kvcalloc()<br /> <br /> Commit 7661809d493b ("mm: don&amp;#39;t allow oversized kvmalloc() calls") add the<br /> oversize check. When the allocation is larger than what kmalloc() supports,<br /> the following warning triggered:<br /> <br /> WARNING: CPU: 0 PID: 8408 at mm/util.c:597 kvmalloc_node+0x108/0x110 mm/util.c:597<br /> Modules linked in:<br /> CPU: 0 PID: 8408 Comm: syz-executor221 Not tainted 5.14.0-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:kvmalloc_node+0x108/0x110 mm/util.c:597<br /> Call Trace:<br /> kvmalloc include/linux/mm.h:806 [inline]<br /> kvmalloc_array include/linux/mm.h:824 [inline]<br /> kvcalloc include/linux/mm.h:829 [inline]<br /> check_btf_line kernel/bpf/verifier.c:9925 [inline]<br /> check_btf_info kernel/bpf/verifier.c:10049 [inline]<br /> bpf_check+0xd634/0x150d0 kernel/bpf/verifier.c:13759<br /> bpf_prog_load kernel/bpf/syscall.c:2301 [inline]<br /> __sys_bpf+0x11181/0x126e0 kernel/bpf/syscall.c:4587<br /> __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]<br /> __x64_sys_bpf+0x78/0x90 kernel/bpf/syscall.c:4689<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-rdma: destroy cm id before destroy qp to avoid use after free<br /> <br /> We should always destroy cm_id before destroy qp to avoid to get cma<br /> event after qp was destroyed, which may lead to use after free.<br /> In RDMA connection establishment error flow, don&amp;#39;t destroy qp in cm<br /> event handler.Just report cm_error to upper level, qp will be destroy<br /> in nvme_rdma_alloc_queue() after destroy cm id.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: fix UAF by grabbing blkcg lock before destroying blkg pd<br /> <br /> KASAN reports a use-after-free report when doing fuzz test:<br /> <br /> [693354.104835] ==================================================================<br /> [693354.105094] BUG: KASAN: use-after-free in bfq_io_set_weight_legacy+0xd3/0x160<br /> [693354.105336] Read of size 4 at addr ffff888be0a35664 by task sh/1453338<br /> <br /> [693354.105607] CPU: 41 PID: 1453338 Comm: sh Kdump: loaded Not tainted 4.18.0-147<br /> [693354.105610] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 0.81 07/02/2018<br /> [693354.105612] Call Trace:<br /> [693354.105621] dump_stack+0xf1/0x19b<br /> [693354.105626] ? show_regs_print_info+0x5/0x5<br /> [693354.105634] ? printk+0x9c/0xc3<br /> [693354.105638] ? cpumask_weight+0x1f/0x1f<br /> [693354.105648] print_address_description+0x70/0x360<br /> [693354.105654] kasan_report+0x1b2/0x330<br /> [693354.105659] ? bfq_io_set_weight_legacy+0xd3/0x160<br /> [693354.105665] ? bfq_io_set_weight_legacy+0xd3/0x160<br /> [693354.105670] bfq_io_set_weight_legacy+0xd3/0x160<br /> [693354.105675] ? bfq_cpd_init+0x20/0x20<br /> [693354.105683] cgroup_file_write+0x3aa/0x510<br /> [693354.105693] ? ___slab_alloc+0x507/0x540<br /> [693354.105698] ? cgroup_file_poll+0x60/0x60<br /> [693354.105702] ? 0xffffffff89600000<br /> [693354.105708] ? usercopy_abort+0x90/0x90<br /> [693354.105716] ? mutex_lock+0xef/0x180<br /> [693354.105726] kernfs_fop_write+0x1ab/0x280<br /> [693354.105732] ? cgroup_file_poll+0x60/0x60<br /> [693354.105738] vfs_write+0xe7/0x230<br /> [693354.105744] ksys_write+0xb0/0x140<br /> [693354.105749] ? __ia32_sys_read+0x50/0x50<br /> [693354.105760] do_syscall_64+0x112/0x370<br /> [693354.105766] ? syscall_return_slowpath+0x260/0x260<br /> [693354.105772] ? do_page_fault+0x9b/0x270<br /> [693354.105779] ? prepare_exit_to_usermode+0xf9/0x1a0<br /> [693354.105784] ? enter_from_user_mode+0x30/0x30<br /> [693354.105793] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> [693354.105875] Allocated by task 1453337:<br /> [693354.106001] kasan_kmalloc+0xa0/0xd0<br /> [693354.106006] kmem_cache_alloc_node_trace+0x108/0x220<br /> [693354.106010] bfq_pd_alloc+0x96/0x120<br /> [693354.106015] blkcg_activate_policy+0x1b7/0x2b0<br /> [693354.106020] bfq_create_group_hierarchy+0x1e/0x80<br /> [693354.106026] bfq_init_queue+0x678/0x8c0<br /> [693354.106031] blk_mq_init_sched+0x1f8/0x460<br /> [693354.106037] elevator_switch_mq+0xe1/0x240<br /> [693354.106041] elevator_switch+0x25/0x40<br /> [693354.106045] elv_iosched_store+0x1a1/0x230<br /> [693354.106049] queue_attr_store+0x78/0xb0<br /> [693354.106053] kernfs_fop_write+0x1ab/0x280<br /> [693354.106056] vfs_write+0xe7/0x230<br /> [693354.106060] ksys_write+0xb0/0x140<br /> [693354.106064] do_syscall_64+0x112/0x370<br /> [693354.106069] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> [693354.106114] Freed by task 1453336:<br /> [693354.106225] __kasan_slab_free+0x130/0x180<br /> [693354.106229] kfree+0x90/0x1b0<br /> [693354.106233] blkcg_deactivate_policy+0x12c/0x220<br /> [693354.106238] bfq_exit_queue+0xf5/0x110<br /> [693354.106241] blk_mq_exit_sched+0x104/0x130<br /> [693354.106245] __elevator_exit+0x45/0x60<br /> [693354.106249] elevator_switch_mq+0xd6/0x240<br /> [693354.106253] elevator_switch+0x25/0x40<br /> [693354.106257] elv_iosched_store+0x1a1/0x230<br /> [693354.106261] queue_attr_store+0x78/0xb0<br /> [693354.106264] kernfs_fop_write+0x1ab/0x280<br /> [693354.106268] vfs_write+0xe7/0x230<br /> [693354.106271] ksys_write+0xb0/0x140<br /> [693354.106275] do_syscall_64+0x112/0x370<br /> [693354.106280] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> [693354.106329] The buggy address belongs to the object at ffff888be0a35580<br /> which belongs to the cache kmalloc-1k of size 1024<br /> [693354.106736] The buggy address is located 228 bytes inside of<br /> 1024-byte region [ffff888be0a35580, ffff888be0a35980)<br /> [693354.107114] The buggy address belongs to the page:<br /> [693354.107273] page:ffffea002f828c00 count:1 mapcount:0 mapping:ffff888107c17080 index:0x0 compound_mapcount: 0<br /> [693354.107606] flags: 0x17ffffc0008100(slab|head)<br /> [693354.107760] raw: 0017ffffc0008100 ffffea002fcbc808 ffffea0030bd3a08 ffff888107c17080<br /> [693354.108020] r<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: amd_sfh: Fix potential NULL pointer dereference<br /> <br /> devm_add_action_or_reset() can suddenly invoke amd_mp2_pci_remove() at<br /> registration that will cause NULL pointer dereference since<br /> corresponding data is not initialized yet. The patch moves<br /> initialization of data before devm_add_action_or_reset().<br /> <br /> Found by Linux Driver Verification project (linuxtesting.org).<br /> <br /> [jkosina@suse.cz: rebase]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Fix DSP oops stack dump output contents<br /> <br /> Fix @buf arg given to hex_dump_to_buffer() and stack address used<br /> in dump error output.