Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs<br /> <br /> Fan speed minimum can be enforced from sysfs. For example, setting<br /> current fan speed to 20 is used to enforce fan speed to be at 100%<br /> speed, 19 - to be not below 90% speed, etcetera. This feature provides<br /> ability to limit fan speed according to some system wise<br /> considerations, like absence of some replaceable units or high system<br /> ambient temperature.<br /> <br /> Request for changing fan minimum speed is configuration request and can<br /> be set only through &amp;#39;sysfs&amp;#39; write procedure. In this situation value of<br /> argument &amp;#39;state&amp;#39; is above nominal fan speed maximum.<br /> <br /> Return non-zero code in this case to avoid<br /> thermal_cooling_device_stats_update() call, because in this case<br /> statistics update violates thermal statistics table range.<br /> The issues is observed in case kernel is configured with option<br /> CONFIG_THERMAL_STATISTICS.<br /> <br /> Here is the trace from KASAN:<br /> [ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0<br /> [ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444<br /> [ 159.545625] Call Trace:<br /> [ 159.548366] dump_stack+0x92/0xc1<br /> [ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0<br /> [ 159.635869] thermal_zone_device_update+0x345/0x780<br /> [ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0<br /> [ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core]<br /> [ 159.700972] ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core]<br /> [ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core]<br /> [ 160.070233] RIP: 0033:0x7fd995909970<br /> [ 160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 3d 01 f0 ff ..<br /> [ 160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970<br /> [ 160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001<br /> [ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700<br /> [ 160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013<br /> [ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013<br /> [ 160.143671]<br /> [ 160.145338] Allocated by task 2924:<br /> [ 160.149242] kasan_save_stack+0x19/0x40<br /> [ 160.153541] __kasan_kmalloc+0x7f/0xa0<br /> [ 160.157743] __kmalloc+0x1a2/0x2b0<br /> [ 160.161552] thermal_cooling_device_setup_sysfs+0xf9/0x1a0<br /> [ 160.167687] __thermal_cooling_device_register+0x1b5/0x500<br /> [ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0<br /> [ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan]<br /> [ 160.248140]<br /> [ 160.249807] The buggy address belongs to the object at ffff888116163400<br /> [ 160.249807] which belongs to the cache kmalloc-1k of size 1024<br /> [ 160.263814] The buggy address is located 64 bytes to the right of<br /> [ 160.263814] 1024-byte region [ffff888116163400, ffff888116163800)<br /> [ 160.277536] The buggy address belongs to the page:<br /> [ 160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160<br /> [ 160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0<br /> [ 160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2)<br /> [ 160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0<br /> [ 160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000<br /> [ 160.327033] page dumped because: kasan: bad access detected<br /> [ 160.333270]<br /> [ 160.334937] Memory state around the buggy address:<br /> [ 160.356469] &gt;ffff888116163800: fc ..

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: unlink table before deleting it<br /> <br /> syzbot reports following UAF:<br /> BUG: KASAN: use-after-free in memcmp+0x18f/0x1c0 lib/string.c:955<br /> nla_strcmp+0xf2/0x130 lib/nlattr.c:836<br /> nft_table_lookup.part.0+0x1a2/0x460 net/netfilter/nf_tables_api.c:570<br /> nft_table_lookup net/netfilter/nf_tables_api.c:4064 [inline]<br /> nf_tables_getset+0x1b3/0x860 net/netfilter/nf_tables_api.c:4064<br /> nfnetlink_rcv_msg+0x659/0x13f0 net/netfilter/nfnetlink.c:285<br /> netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504<br /> <br /> Problem is that all get operations are lockless, so the commit_mutex<br /> held by nft_rcv_nl_event() isn&amp;#39;t enough to stop a parallel GET request<br /> from doing read-accesses to the table object even after synchronize_rcu().<br /> <br /> To avoid this, unlink the table first and store the table objects in<br /> on-stack scratch space.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap<br /> <br /> Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap<br /> routine in order to fix the following warning reported by syzbot:<br /> <br /> WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]<br /> WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244<br /> Modules linked in:<br /> CPU: 0 PID: 10717 Comm: syz-executor.5 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:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]<br /> RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244<br /> RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216<br /> RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000<br /> RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003<br /> RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100<br /> R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8<br /> R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004<br /> FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600<br /> Call Trace:<br /> ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740<br /> netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089<br /> __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165<br /> __bpf_tx_skb net/core/filter.c:2114 [inline]<br /> __bpf_redirect_no_mac net/core/filter.c:2139 [inline]<br /> __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162<br /> ____bpf_clone_redirect net/core/filter.c:2429 [inline]<br /> bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401<br /> bpf_prog_eeb6f53a69e5c6a2+0x59/0x234<br /> bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline]<br /> __bpf_prog_run include/linux/filter.h:624 [inline]<br /> bpf_prog_run include/linux/filter.h:631 [inline]<br /> bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119<br /> bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663<br /> bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline]<br /> __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605<br /> __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]<br /> __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x4665f9

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.