Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()<br /> <br /> During driver initialization, the pointer of card info, i.e. the<br /> variable &amp;#39;ci&amp;#39; is required. However, the definition of<br /> &amp;#39;com20020pci_id_table&amp;#39; reveals that this field is empty for some<br /> devices, which will cause null pointer dereference when initializing<br /> these devices.<br /> <br /> The following log reveals it:<br /> <br /> [ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> [ 3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci]<br /> [ 3.975181] Call Trace:<br /> [ 3.976208] local_pci_probe+0x13f/0x210<br /> [ 3.977248] pci_device_probe+0x34c/0x6d0<br /> [ 3.977255] ? pci_uevent+0x470/0x470<br /> [ 3.978265] really_probe+0x24c/0x8d0<br /> [ 3.978273] __driver_probe_device+0x1b3/0x280<br /> [ 3.979288] driver_probe_device+0x50/0x370<br /> <br /> Fix this by checking whether the &amp;#39;ci&amp;#39; is a null pointer first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix connection leak<br /> <br /> There&amp;#39;s a potential leak issue under following execution sequence :<br /> <br /> smc_release smc_connect_work<br /> if (sk-&gt;sk_state == SMC_INIT)<br /> send_clc_confirim<br /> tcp_abort();<br /> ...<br /> sk.sk_state = SMC_ACTIVE<br /> smc_close_active<br /> switch(sk-&gt;sk_state) {<br /> ...<br /> case SMC_ACTIVE:<br /> smc_close_final()<br /> // then wait peer closed<br /> <br /> Unfortunately, tcp_abort() may discard CLC CONFIRM messages that are<br /> still in the tcp send buffer, in which case our connection token cannot<br /> be delivered to the server side, which means that we cannot get a<br /> passive close message at all. Therefore, it is impossible for the to be<br /> disconnected at all.<br /> <br /> This patch tries a very simple way to avoid this issue, once the state<br /> has changed to SMC_ACTIVE after tcp_abort(), we can actively abort the<br /> smc connection, considering that the state is SMC_INIT before<br /> tcp_abort(), abandoning the complete disconnection process should not<br /> cause too much problem.<br /> <br /> In fact, this problem may exist as long as the CLC CONFIRM message is<br /> not received by the server. Whether a timer should be added after<br /> smc_close_final() needs to be discussed in the future. But even so, this<br /> patch provides a faster release for connection in above case, it should<br /> also be valuable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: ensure we call ipv6_mc_down() at most once<br /> <br /> There are two reasons for addrconf_notify() to be called with NETDEV_DOWN:<br /> either the network device is actually going down, or IPv6 was disabled<br /> on the interface.<br /> <br /> If either of them stays down while the other is toggled, we repeatedly<br /> call the code for NETDEV_DOWN, including ipv6_mc_down(), while never<br /> calling the corresponding ipv6_mc_up() in between. This will cause a<br /> new entry in idev-&gt;mc_tomb to be allocated for each multicast group<br /> the interface is subscribed to, which in turn leaks one struct ifmcaddr6<br /> per nontrivial multicast group the interface is subscribed to.<br /> <br /> The following reproducer will leak at least $n objects:<br /> <br /> ip addr add ff2e::4242/32 dev eth0 autojoin<br /> sysctl -w net.ipv6.conf.eth0.disable_ipv6=1<br /> for i in $(seq 1 $n); do<br /> ip link set up eth0; ip link set down eth0<br /> done<br /> <br /> Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the<br /> sysctl net.ipv6.conf.eth0.forwarding to 1 (=&gt; subscribing to ff02::2)<br /> can also be used to create a nontrivial idev-&gt;mc_list, which will the<br /> leak objects with the right up-down-sequence.<br /> <br /> Based on both sources for NETDEV_DOWN events the interface IPv6 state<br /> should be considered:<br /> <br /> - not ready if the network interface is not ready OR IPv6 is disabled<br /> for it<br /> - ready if the network interface is ready AND IPv6 is enabled for it<br /> <br /> The functions ipv6_mc_up() and ipv6_down() should only be run when this<br /> state changes.<br /> <br /> Implement this by remembering when the IPv6 state is ready, and only<br /> run ipv6_mc_down() if it actually changed from ready to not ready.<br /> <br /> The other direction (not ready -&gt; ready) already works correctly, as:<br /> <br /> - the interface notification triggered codepath for NETDEV_UP /<br /> NETDEV_CHANGE returns early if ipv6 is disabled, and<br /> - the disable_ipv6=0 triggered codepath skips fully initializing the<br /> interface as long as addrconf_link_ready(dev) returns false<br /> - calling ipv6_mc_up() repeatedly does not leak anything

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_queue: fix possible use-after-free<br /> <br /> Eric Dumazet says:<br /> The sock_hold() side seems suspect, because there is no guarantee<br /> that sk_refcnt is not already 0.<br /> <br /> On failure, we cannot queue the packet and need to indicate an<br /> error. The packet will be dropped by the caller.<br /> <br /> v2: split skb prefetch hunk into separate change

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: fix use-after-free in __nf_register_net_hook()<br /> <br /> We must not dereference @new_hooks after nf_hook_mutex has been released,<br /> because other threads might have freed our allocated hooks already.<br /> <br /> BUG: KASAN: use-after-free in nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]<br /> BUG: KASAN: use-after-free in hooks_validate net/netfilter/core.c:171 [inline]<br /> BUG: KASAN: use-after-free in __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438<br /> Read of size 2 at addr ffff88801c1a8000 by task syz-executor237/4430<br /> <br /> CPU: 1 PID: 4430 Comm: syz-executor237 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0x8d/0x336 mm/kasan/report.c:255<br /> __kasan_report mm/kasan/report.c:442 [inline]<br /> kasan_report.cold+0x83/0xdf mm/kasan/report.c:459<br /> nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]<br /> hooks_validate net/netfilter/core.c:171 [inline]<br /> __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438<br /> nf_register_net_hook+0x114/0x170 net/netfilter/core.c:571<br /> nf_register_net_hooks+0x59/0xc0 net/netfilter/core.c:587<br /> nf_synproxy_ipv6_init+0x85/0xe0 net/netfilter/nf_synproxy_core.c:1218<br /> synproxy_tg6_check+0x30d/0x560 net/ipv6/netfilter/ip6t_SYNPROXY.c:81<br /> xt_check_target+0x26c/0x9e0 net/netfilter/x_tables.c:1038<br /> check_target net/ipv6/netfilter/ip6_tables.c:530 [inline]<br /> find_check_entry.constprop.0+0x7f1/0x9e0 net/ipv6/netfilter/ip6_tables.c:573<br /> translate_table+0xc8b/0x1750 net/ipv6/netfilter/ip6_tables.c:735<br /> do_replace net/ipv6/netfilter/ip6_tables.c:1153 [inline]<br /> do_ip6t_set_ctl+0x56e/0xb90 net/ipv6/netfilter/ip6_tables.c:1639<br /> nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101<br /> ipv6_setsockopt+0x122/0x180 net/ipv6/ipv6_sockglue.c:1024<br /> rawv6_setsockopt+0xd3/0x6a0 net/ipv6/raw.c:1084<br /> __sys_setsockopt+0x2db/0x610 net/socket.c:2180<br /> __do_sys_setsockopt net/socket.c:2191 [inline]<br /> __se_sys_setsockopt net/socket.c:2188 [inline]<br /> __x64_sys_setsockopt+0xba/0x150 net/socket.c:2188<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:0x7f65a1ace7d9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 71 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f65a1a7f308 EFLAGS: 00000246 ORIG_RAX: 0000000000000036<br /> RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f65a1ace7d9<br /> RDX: 0000000000000040 RSI: 0000000000000029 RDI: 0000000000000003<br /> RBP: 00007f65a1b574c8 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000020000000 R11: 0000000000000246 R12: 00007f65a1b55130<br /> R13: 00007f65a1b574c0 R14: 00007f65a1b24090 R15: 0000000000022000<br /> <br /> <br /> The buggy address belongs to the page:<br /> page:ffffea0000706a00 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1c1a8<br /> flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)<br /> raw: 00fff00000000000 ffffea0001c1b108 ffffea000046dd08 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner tracks the page as freed<br /> page last allocated via order 2, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 4430, ts 1061781545818, free_ts 1061791488993<br /> prep_new_page mm/page_alloc.c:2434 [inline]<br /> get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165<br /> __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389<br /> __alloc_pages_node include/linux/gfp.h:572 [inline]<br /> alloc_pages_node include/linux/gfp.h:595 [inline]<br /> kmalloc_large_node+0x62/0x130 mm/slub.c:4438<br /> __kmalloc_node+0x35a/0x4a0 mm/slub.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blktrace: fix use after free for struct blk_trace<br /> <br /> When tracing the whole disk, &amp;#39;dropped&amp;#39; and &amp;#39;msg&amp;#39; will be created<br /> under &amp;#39;q-&gt;debugfs_dir&amp;#39; and &amp;#39;bt-&gt;dir&amp;#39; is NULL, thus blk_trace_free()<br /> won&amp;#39;t remove those files. What&amp;#39;s worse, the following UAF can be<br /> triggered because of accessing stale &amp;#39;dropped&amp;#39; and &amp;#39;msg&amp;#39;:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in blk_dropped_read+0x89/0x100<br /> Read of size 4 at addr ffff88816912f3d8 by task blktrace/1188<br /> <br /> CPU: 27 PID: 1188 Comm: blktrace Not tainted 5.17.0-rc4-next-20220217+ #469<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-4<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> print_address_description.constprop.0.cold+0xab/0x381<br /> ? blk_dropped_read+0x89/0x100<br /> ? blk_dropped_read+0x89/0x100<br /> kasan_report.cold+0x83/0xdf<br /> ? blk_dropped_read+0x89/0x100<br /> kasan_check_range+0x140/0x1b0<br /> blk_dropped_read+0x89/0x100<br /> ? blk_create_buf_file_callback+0x20/0x20<br /> ? kmem_cache_free+0xa1/0x500<br /> ? do_sys_openat2+0x258/0x460<br /> full_proxy_read+0x8f/0xc0<br /> vfs_read+0xc6/0x260<br /> ksys_read+0xb9/0x150<br /> ? vfs_write+0x3d0/0x3d0<br /> ? fpregs_assert_state_consistent+0x55/0x60<br /> ? exit_to_user_mode_prepare+0x39/0x1e0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7fbc080d92fd<br /> Code: ce 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 1<br /> RSP: 002b:00007fbb95ff9cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000000<br /> RAX: ffffffffffffffda RBX: 00007fbb95ff9dc0 RCX: 00007fbc080d92fd<br /> RDX: 0000000000000100 RSI: 00007fbb95ff9cc0 RDI: 0000000000000045<br /> RBP: 0000000000000045 R08: 0000000000406299 R09: 00000000fffffffd<br /> R10: 000000000153afa0 R11: 0000000000000293 R12: 00007fbb780008c0<br /> R13: 00007fbb78000938 R14: 0000000000608b30 R15: 00007fbb780029c8<br /> <br /> <br /> Allocated by task 1050:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x81/0xa0<br /> do_blk_trace_setup+0xcb/0x410<br /> __blk_trace_setup+0xac/0x130<br /> blk_trace_ioctl+0xe9/0x1c0<br /> blkdev_ioctl+0xf1/0x390<br /> __x64_sys_ioctl+0xa5/0xe0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Freed by task 1050:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_set_free_info+0x20/0x30<br /> __kasan_slab_free+0x103/0x180<br /> kfree+0x9a/0x4c0<br /> __blk_trace_remove+0x53/0x70<br /> blk_trace_ioctl+0x199/0x1c0<br /> blkdev_common_ioctl+0x5e9/0xb30<br /> blkdev_ioctl+0x1a5/0x390<br /> __x64_sys_ioctl+0xa5/0xe0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The buggy address belongs to the object at ffff88816912f380<br /> which belongs to the cache kmalloc-96 of size 96<br /> The buggy address is located 88 bytes inside of<br /> 96-byte region [ffff88816912f380, ffff88816912f3e0)<br /> The buggy address belongs to the page:<br /> page:000000009a1b4e7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0f<br /> flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)<br /> raw: 0017ffffc0000200 ffffea00044f1100 dead000000000002 ffff88810004c780<br /> raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff88816912f280: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> ffff88816912f300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> &gt;ffff88816912f380: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> ^<br /> ffff88816912f400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> ffff88816912f480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/netfront: destroy queues before real_num_tx_queues is zeroed<br /> <br /> xennet_destroy_queues() relies on info-&gt;netdev-&gt;real_num_tx_queues to<br /> delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5<br /> ("net-sysfs: update the queue counts in the unregistration path"),<br /> unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two<br /> facts together means, that xennet_destroy_queues() called from<br /> xennet_remove() cannot do its job, because it&amp;#39;s called after<br /> unregister_netdev(). This results in kfree-ing queues that are still<br /> linked in napi, which ultimately crashes:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226<br /> RIP: 0010:free_netdev+0xa3/0x1a0<br /> Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00<br /> RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff<br /> RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050<br /> R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680<br /> FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0<br /> Call Trace:<br /> <br /> xennet_remove+0x13d/0x300 [xen_netfront]<br /> xenbus_dev_remove+0x6d/0xf0<br /> __device_release_driver+0x17a/0x240<br /> device_release_driver+0x24/0x30<br /> bus_remove_device+0xd8/0x140<br /> device_del+0x18b/0x410<br /> ? _raw_spin_unlock+0x16/0x30<br /> ? klist_iter_exit+0x14/0x20<br /> ? xenbus_dev_request_and_reply+0x80/0x80<br /> device_unregister+0x13/0x60<br /> xenbus_dev_changed+0x18e/0x1f0<br /> xenwatch_thread+0xc0/0x1a0<br /> ? do_wait_intr_irq+0xa0/0xa0<br /> kthread+0x16b/0x190<br /> ? set_kthread_struct+0x40/0x40<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Fix this by calling xennet_destroy_queues() from xennet_uninit(),<br /> when real_num_tx_queues is still available. This ensures that queues are<br /> destroyed when real_num_tx_queues is set to 0, regardless of how<br /> unregister_netdev() was called.<br /> <br /> Originally reported at<br /> https://github.com/QubesOS/qubes-issues/issues/7257

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: core: Fix TZ_GET_TRIP NULL pointer dereference<br /> <br /> Do not call get_trip_hyst() from thermal_genl_cmd_tz_get_trip() if<br /> the thermal zone does not define one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix double list_add when enabling VMD in scalable mode<br /> <br /> When enabling VMD and IOMMU scalable mode, the following kernel panic<br /> call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids<br /> CPU) during booting:<br /> <br /> pci 0000:59:00.5: Adding to iommu group 42<br /> ...<br /> vmd 0000:59:00.5: PCI host bridge to bus 10000:80<br /> pci 10000:80:01.0: [8086:352a] type 01 class 0x060400<br /> pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]<br /> pci 10000:80:01.0: enabling Extended Tags<br /> pci 10000:80:01.0: PME# supported from D0 D3hot D3cold<br /> pci 10000:80:01.0: DMAR: Setup RID2PASID failed<br /> pci 10000:80:01.0: Failed to add to iommu group 42: -16<br /> pci 10000:80:03.0: [8086:352b] type 01 class 0x060400<br /> pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]<br /> pci 10000:80:03.0: enabling Extended Tags<br /> pci 10000:80:03.0: PME# supported from D0 D3hot D3cold<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:29!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7<br /> Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022<br /> Workqueue: events work_for_cpu_fn<br /> RIP: 0010:__list_add_valid.cold+0x26/0x3f<br /> Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f<br /> 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1<br /> fe ff 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9<br /> 9e e8 8b b1 fe<br /> RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246<br /> RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8<br /> RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20<br /> RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888<br /> R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0<br /> R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70<br /> FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> intel_pasid_alloc_table+0x9c/0x1d0<br /> dmar_insert_one_dev_info+0x423/0x540<br /> ? device_to_iommu+0x12d/0x2f0<br /> intel_iommu_attach_device+0x116/0x290<br /> __iommu_attach_device+0x1a/0x90<br /> iommu_group_add_device+0x190/0x2c0<br /> __iommu_probe_device+0x13e/0x250<br /> iommu_probe_device+0x24/0x150<br /> iommu_bus_notifier+0x69/0x90<br /> blocking_notifier_call_chain+0x5a/0x80<br /> device_add+0x3db/0x7b0<br /> ? arch_memremap_can_ram_remap+0x19/0x50<br /> ? memremap+0x75/0x140<br /> pci_device_add+0x193/0x1d0<br /> pci_scan_single_device+0xb9/0xf0<br /> pci_scan_slot+0x4c/0x110<br /> pci_scan_child_bus_extend+0x3a/0x290<br /> vmd_enable_domain.constprop.0+0x63e/0x820<br /> vmd_probe+0x163/0x190<br /> local_pci_probe+0x42/0x80<br /> work_for_cpu_fn+0x13/0x20<br /> process_one_work+0x1e2/0x3b0<br /> worker_thread+0x1c4/0x3a0<br /> ? rescuer_thread+0x370/0x370<br /> kthread+0xc7/0xf0<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x1f/0x30<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> ...<br /> Kernel panic - not syncing: Fatal exception<br /> Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)<br /> ---[ end Kernel panic - not syncing: Fatal exception ]---<br /> <br /> The following &amp;#39;lspci&amp;#39; output shows devices &amp;#39;10000:80:*&amp;#39; are subdevices of<br /> the VMD device 0000:59:00.5:<br /> <br /> $ lspci<br /> ...<br /> 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)<br /> ...<br /> 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)<br /> 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)<br /> 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)<br /> 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)<br /> 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]<br /> 10000:82:00<br /> ---truncated---

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 /> iwlwifi: mvm: check debugfs_dir ptr before use<br /> <br /> When "debugfs=off" is used on the kernel command line, iwiwifi&amp;#39;s<br /> mvm module uses an invalid/unchecked debugfs_dir pointer and causes<br /> a BUG:<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000004f<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP<br /> CPU: 1 PID: 503 Comm: modprobe Tainted: G W 5.17.0-rc5 #7<br /> Hardware name: Dell Inc. Inspiron 15 5510/076F7Y, BIOS 2.4.1 11/05/2021<br /> RIP: 0010:iwl_mvm_dbgfs_register+0x692/0x700 [iwlmvm]<br /> Code: 69 a0 be 80 01 00 00 48 c7 c7 50 73 6a a0 e8 95 cf ee e0 48 8b 83 b0 1e 00 00 48 c7 c2 54 73 6a a0 be 64 00 00 00 48 8d 7d 8c 8b 48 50 e8 15 22 07 e1 48 8b 43 28 48 8d 55 8c 48 c7 c7 5f 73<br /> RSP: 0018:ffffc90000a0ba68 EFLAGS: 00010246<br /> RAX: ffffffffffffffff RBX: ffff88817d6e3328 RCX: ffff88817d6e3328<br /> RDX: ffffffffa06a7354 RSI: 0000000000000064 RDI: ffffc90000a0ba6c<br /> RBP: ffffc90000a0bae0 R08: ffffffff824e4880 R09: ffffffffa069d620<br /> R10: ffffc90000a0ba00 R11: ffffffffffffffff R12: 0000000000000000<br /> R13: ffffc90000a0bb28 R14: ffff88817d6e3328 R15: ffff88817d6e3320<br /> FS: 00007f64dd92d740(0000) GS:ffff88847f640000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000000004f CR3: 000000016fc79001 CR4: 0000000000770ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? iwl_mvm_mac_setup_register+0xbdc/0xda0 [iwlmvm]<br /> iwl_mvm_start_post_nvm+0x71/0x100 [iwlmvm]<br /> iwl_op_mode_mvm_start+0xab8/0xb30 [iwlmvm]<br /> _iwl_op_mode_start+0x6f/0xd0 [iwlwifi]<br /> iwl_opmode_register+0x6a/0xe0 [iwlwifi]<br /> ? 0xffffffffa0231000<br /> iwl_mvm_init+0x35/0x1000 [iwlmvm]<br /> ? 0xffffffffa0231000<br /> do_one_initcall+0x5a/0x1b0<br /> ? kmem_cache_alloc+0x1e5/0x2f0<br /> ? do_init_module+0x1e/0x220<br /> do_init_module+0x48/0x220<br /> load_module+0x2602/0x2bc0<br /> ? __kernel_read+0x145/0x2e0<br /> ? kernel_read_file+0x229/0x290<br /> __do_sys_finit_module+0xc5/0x130<br /> ? __do_sys_finit_module+0xc5/0x130<br /> __x64_sys_finit_module+0x13/0x20<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f64dda564dd<br /> Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1b 29 0f 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffdba393f88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f64dda564dd<br /> RDX: 0000000000000000 RSI: 00005575399e2ab2 RDI: 0000000000000001<br /> RBP: 000055753a91c5e0 R08: 0000000000000000 R09: 0000000000000002<br /> R10: 0000000000000001 R11: 0000000000000246 R12: 00005575399e2ab2<br /> R13: 000055753a91ceb0 R14: 0000000000000000 R15: 000055753a923018<br /> <br /> Modules linked in: btintel(+) btmtk bluetooth vfat snd_hda_codec_hdmi fat snd_hda_codec_realtek snd_hda_codec_generic iwlmvm(+) snd_sof_pci_intel_tgl mac80211 snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence soundwire_bus snd_sof_intel_hda snd_sof_pci snd_sof snd_sof_xtensa_dsp snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core btrfs snd_compress snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec raid6_pq iwlwifi snd_hda_core snd_pcm snd_timer snd soundcore cfg80211 intel_ish_ipc(+) thunderbolt rfkill intel_ishtp ucsi_acpi wmi i2c_hid_acpi i2c_hid evdev<br /> CR2: 000000000000004f<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Check the debugfs_dir pointer for an error before using it.<br /> <br /> [change to make both conditional]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix double free race when mount fails in cifs_get_root()<br /> <br /> When cifs_get_root() fails during cifs_smb3_do_mount() we call<br /> deactivate_locked_super() which eventually will call delayed_free() which<br /> will free the context.<br /> In this situation we should not proceed to enter the out: section in<br /> cifs_smb3_do_mount() and free the same resources a second time.<br /> <br /> [Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60<br /> [Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0<br /> <br /> [Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4<br /> [Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019<br /> [Thu Feb 10 12:59:06 2022] Call Trace:<br /> [Thu Feb 10 12:59:06 2022] <br /> [Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78<br /> [Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150<br /> [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60<br /> [Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117<br /> [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60<br /> [Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0<br /> [Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60<br /> [Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0<br /> [Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0<br /> [Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20<br /> [Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140<br /> [Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10<br /> [Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b<br /> [Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150<br /> [Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30<br /> [Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0<br /> ...<br /> [Thu Feb 10 12:59:07 2022] Freed by task 58179:<br /> [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50<br /> [Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30<br /> [Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40<br /> [Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170<br /> [Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20<br /> [Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0<br /> [Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520<br /> [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs]<br /> [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs]<br /> [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140<br /> [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0<br /> [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210<br /> [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0<br /> [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> [Thu Feb 10 12:59:07 2022] Last potentially related work creation:<br /> [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50<br /> [Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0<br /> [Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10<br /> [Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0<br /> [Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs]<br /> [Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs]<br /> [Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0<br /> [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs]<br /> [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs]<br /> [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140<br /> [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0<br /> [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210<br /> [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0<br /> [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae