Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix kernel crash when 1588 is received on HIP08 devices<br /> <br /> The HIP08 devices does not register the ptp devices, so the<br /> hdev-&gt;ptp is NULL, but the hardware can receive 1588 messages,<br /> and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the<br /> access of hdev-&gt;ptp-&gt;flags will cause a kernel crash:<br /> <br /> [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018<br /> [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018<br /> ...<br /> [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]<br /> [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]<br /> [ 5889.279101] sp : ffff800012c3bc50<br /> [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040<br /> [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500<br /> [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000<br /> [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000<br /> [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080<br /> [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000<br /> [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000<br /> [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000<br /> [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df<br /> [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000<br /> [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d<br /> [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480<br /> [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000<br /> [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000<br /> [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080<br /> [ 5889.378857] Call trace:<br /> [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]<br /> [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]<br /> [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]<br /> [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]<br /> [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]<br /> [ 5889.411084] napi_poll+0xcc/0x264<br /> [ 5889.415329] net_rx_action+0xd4/0x21c<br /> [ 5889.419911] __do_softirq+0x130/0x358<br /> [ 5889.424484] irq_exit+0x134/0x154<br /> [ 5889.428700] __handle_domain_irq+0x88/0xf0<br /> [ 5889.433684] gic_handle_irq+0x78/0x2c0<br /> [ 5889.438319] el1_irq+0xb8/0x140<br /> [ 5889.442354] arch_cpu_idle+0x18/0x40<br /> [ 5889.446816] default_idle_call+0x5c/0x1c0<br /> [ 5889.451714] cpuidle_idle_call+0x174/0x1b0<br /> [ 5889.456692] do_idle+0xc8/0x160<br /> [ 5889.460717] cpu_startup_entry+0x30/0xfc<br /> [ 5889.465523] secondary_start_kernel+0x158/0x1ec<br /> [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)<br /> [ 5889.477950] SMP: stopping secondary CPUs<br /> [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95<br /> [ 5890.522951] Starting crashdump kernel...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()<br /> <br /> Apply the same fix than ones found in :<br /> <br /> 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")<br /> 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")<br /> <br /> We have to save skb-&gt;network_header in a temporary variable<br /> in order to be able to recompute the network_header pointer<br /> after a pskb_inet_may_pull() call.<br /> <br /> pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.<br /> <br /> syzbot reported:<br /> BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]<br /> BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409<br /> __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]<br /> ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409<br /> __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389<br /> ipgre_rcv net/ipv4/ip_gre.c:411 [inline]<br /> gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447<br /> gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163<br /> ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254<br /> dst_input include/net/dst.h:461 [inline]<br /> ip_rcv_finish net/ipv4/ip_input.c:449 [inline]<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569<br /> __netif_receive_skb_one_core net/core/dev.c:5534 [inline]<br /> __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648<br /> netif_receive_skb_internal net/core/dev.c:5734 [inline]<br /> netif_receive_skb+0x58/0x660 net/core/dev.c:5793<br /> tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556<br /> tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009<br /> tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055<br /> call_write_iter include/linux/fs.h:2087 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0xb6b/0x1520 fs/read_write.c:590<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0x93/0xd0 fs/read_write.c:652<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Uninit was created at:<br /> __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590<br /> alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133<br /> alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204<br /> skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909<br /> tun_build_skb drivers/net/tun.c:1686 [inline]<br /> tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826<br /> tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055<br /> call_write_iter include/linux/fs.h:2087 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0xb6b/0x1520 fs/read_write.c:590<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0x93/0xd0 fs/read_write.c:652<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix stackmap overflow check on 32-bit arches<br /> <br /> The stackmap code relies on roundup_pow_of_two() to compute the number<br /> of hash buckets, and contains an overflow check by checking if the<br /> resulting value is 0. However, on 32-bit arches, the roundup code itself<br /> can overflow by doing a 32-bit left-shift of an unsigned long value,<br /> which is undefined behaviour, so it is not guaranteed to truncate<br /> neatly. This was triggered by syzbot on the DEVMAP_HASH type, which<br /> contains the same check, copied from the hashtab code.<br /> <br /> The commit in the fixes tag actually attempted to fix this, but the fix<br /> did not account for the UB, so the fix only works on CPUs where an<br /> overflow does result in a neat truncation to zero, which is not<br /> guaranteed. Checking the value before rounding does not have this<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix hashtab overflow check on 32-bit arches<br /> <br /> The hashtab code relies on roundup_pow_of_two() to compute the number of<br /> hash buckets, and contains an overflow check by checking if the<br /> resulting value is 0. However, on 32-bit arches, the roundup code itself<br /> can overflow by doing a 32-bit left-shift of an unsigned long value,<br /> which is undefined behaviour, so it is not guaranteed to truncate<br /> neatly. This was triggered by syzbot on the DEVMAP_HASH type, which<br /> contains the same check, copied from the hashtab code. So apply the same<br /> fix to hashtab, by moving the overflow check to before the roundup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix DEVMAP_HASH overflow check on 32-bit arches<br /> <br /> The devmap code allocates a number hash buckets equal to the next power<br /> of two of the max_entries value provided when creating the map. When<br /> rounding up to the next power of two, the 32-bit variable storing the<br /> number of buckets can overflow, and the code checks for overflow by<br /> checking if the truncated 32-bit value is equal to 0. However, on 32-bit<br /> arches the rounding up itself can overflow mid-way through, because it<br /> ends up doing a left-shift of 32 bits on an unsigned long value. If the<br /> size of an unsigned long is four bytes, this is undefined behaviour, so<br /> there is no guarantee that we&amp;#39;ll end up with a nice and tidy 0-value at<br /> the end.<br /> <br /> Syzbot managed to turn this into a crash on arm32 by creating a<br /> DEVMAP_HASH with max_entries &gt; 0x80000000 and then trying to update it.<br /> Fix this by moving the overflow check to before the rounding up<br /> operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: af_bluetooth: Fix deadlock<br /> <br /> Attemting to do sock_lock on .recvmsg may cause a deadlock as shown<br /> bellow, so instead of using sock_sock this uses sk_receive_queue.lock<br /> on bt_sock_ioctl to avoid the UAF:<br /> <br /> INFO: task kworker/u9:1:121 blocked for more than 30 seconds.<br /> Not tainted 6.7.6-lemon #183<br /> Workqueue: hci0 hci_rx_work<br /> Call Trace:<br /> <br /> __schedule+0x37d/0xa00<br /> schedule+0x32/0xe0<br /> __lock_sock+0x68/0xa0<br /> ? __pfx_autoremove_wake_function+0x10/0x10<br /> lock_sock_nested+0x43/0x50<br /> l2cap_sock_recv_cb+0x21/0xa0<br /> l2cap_recv_frame+0x55b/0x30a0<br /> ? psi_task_switch+0xeb/0x270<br /> ? finish_task_switch.isra.0+0x93/0x2a0<br /> hci_rx_work+0x33a/0x3f0<br /> process_one_work+0x13a/0x2f0<br /> worker_thread+0x2f0/0x410<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe0/0x110<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: Fix memory leak<br /> <br /> This checks if CONFIG_DEV_COREDUMP is enabled before attempting to clone<br /> the skb and also make sure btmtk_process_coredump frees the skb passed<br /> following the same logic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: msft: Fix memory leak<br /> <br /> Fix leaking buffer allocated to send MSFT_OP_LE_MONITOR_ADVERTISEMENT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: Fix possible buffer overflow<br /> <br /> struct hci_dev_info has a fixed size name[8] field so in the event that<br /> hdev-&gt;name is bigger than that strcpy would attempt to write past its<br /> size, so this fixes this problem by switching to use strscpy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btrtl: fix out of bounds memory access<br /> <br /> The problem is detected by KASAN.<br /> btrtl driver uses private hci data to store &amp;#39;struct btrealtek_data&amp;#39;.<br /> If btrtl driver is used with btusb, then memory for private hci data<br /> is allocated in btusb. But no private data is allocated after hci_dev,<br /> when btrtl is used with hci_h5.<br /> <br /> This commit adds memory allocation for hci_h5 case.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in btrtl_initialize+0x6cc/0x958 [btrtl]<br /> Write of size 8 at addr ffff00000f5a5748 by task kworker/u9:0/76<br /> <br /> Hardware name: Pine64 PinePhone (1.2) (DT)<br /> Workqueue: hci0 hci_power_on [bluetooth]<br /> Call trace:<br /> dump_backtrace+0x9c/0x128<br /> show_stack+0x20/0x38<br /> dump_stack_lvl+0x48/0x60<br /> print_report+0xf8/0x5d8<br /> kasan_report+0x90/0xd0<br /> __asan_store8+0x9c/0xc0<br /> [btrtl]<br /> h5_btrtl_setup+0xd0/0x2f8 [hci_uart]<br /> h5_setup+0x50/0x80 [hci_uart]<br /> hci_uart_setup+0xd4/0x260 [hci_uart]<br /> hci_dev_open_sync+0x1cc/0xf68 [bluetooth]<br /> hci_dev_do_open+0x34/0x90 [bluetooth]<br /> hci_power_on+0xc4/0x3c8 [bluetooth]<br /> process_one_work+0x328/0x6f0<br /> worker_thread+0x410/0x778<br /> kthread+0x168/0x178<br /> ret_from_fork+0x10/0x20<br /> <br /> Allocated by task 53:<br /> kasan_save_stack+0x3c/0x68<br /> kasan_save_track+0x20/0x40<br /> kasan_save_alloc_info+0x68/0x78<br /> __kasan_kmalloc+0xd4/0xd8<br /> __kmalloc+0x1b4/0x3b0<br /> hci_alloc_dev_priv+0x28/0xa58 [bluetooth]<br /> hci_uart_register_device+0x118/0x4f8 [hci_uart]<br /> h5_serdev_probe+0xf4/0x178 [hci_uart]<br /> serdev_drv_probe+0x54/0xa0<br /> really_probe+0x254/0x588<br /> __driver_probe_device+0xc4/0x210<br /> driver_probe_device+0x64/0x160<br /> __driver_attach_async_helper+0x88/0x158<br /> async_run_entry_fn+0xd0/0x388<br /> process_one_work+0x328/0x6f0<br /> worker_thread+0x410/0x778<br /> kthread+0x168/0x178<br /> ret_from_fork+0x10/0x20<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x3c/0x68<br /> __kasan_record_aux_stack+0xb0/0x150<br /> kasan_record_aux_stack_noalloc+0x14/0x20<br /> __queue_work+0x33c/0x960<br /> queue_work_on+0x98/0xc0<br /> hci_recv_frame+0xc8/0x1e8 [bluetooth]<br /> h5_complete_rx_pkt+0x2c8/0x800 [hci_uart]<br /> h5_rx_payload+0x98/0xb8 [hci_uart]<br /> h5_recv+0x158/0x3d8 [hci_uart]<br /> hci_uart_receive_buf+0xa0/0xe8 [hci_uart]<br /> ttyport_receive_buf+0xac/0x178<br /> flush_to_ldisc+0x130/0x2c8<br /> process_one_work+0x328/0x6f0<br /> worker_thread+0x410/0x778<br /> kthread+0x168/0x178<br /> ret_from_fork+0x10/0x20<br /> <br /> Second to last potentially related work creation:<br /> kasan_save_stack+0x3c/0x68<br /> __kasan_record_aux_stack+0xb0/0x150<br /> kasan_record_aux_stack_noalloc+0x14/0x20<br /> __queue_work+0x788/0x960<br /> queue_work_on+0x98/0xc0<br /> __hci_cmd_sync_sk+0x23c/0x7a0 [bluetooth]<br /> __hci_cmd_sync+0x24/0x38 [bluetooth]<br /> btrtl_initialize+0x760/0x958 [btrtl]<br /> h5_btrtl_setup+0xd0/0x2f8 [hci_uart]<br /> h5_setup+0x50/0x80 [hci_uart]<br /> hci_uart_setup+0xd4/0x260 [hci_uart]<br /> hci_dev_open_sync+0x1cc/0xf68 [bluetooth]<br /> hci_dev_do_open+0x34/0x90 [bluetooth]<br /> hci_power_on+0xc4/0x3c8 [bluetooth]<br /> process_one_work+0x328/0x6f0<br /> worker_thread+0x410/0x778<br /> kthread+0x168/0x178<br /> ret_from_fork+0x10/0x20<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Don&amp;#39;t issue ATS Invalidation request when device is disconnected<br /> <br /> For those endpoint devices connect to system via hotplug capable ports,<br /> users could request a hot reset to the device by flapping device&amp;#39;s link<br /> through setting the slot&amp;#39;s link control register, as pciehp_ist() DLLSC<br /> interrupt sequence response, pciehp will unload the device driver and<br /> then power it off. thus cause an IOMMU device-TLB invalidation (Intel<br /> VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence<br /> target device to be sent and deadly loop to retry that request after ITE<br /> fault triggered in interrupt context.<br /> <br /> That would cause following continuous hard lockup warning and system hang<br /> <br /> [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down<br /> [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present<br /> [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144<br /> [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S<br /> OE kernel version xxxx<br /> [ 4223.822623] Hardware name: vendorname xxxx 666-106,<br /> BIOS 01.01.02.03.01 05/15/2023<br /> [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490<br /> [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b<br /> 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 f6 c6 1<br /> 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39<br /> [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093<br /> [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005<br /> [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340<br /> [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000<br /> [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200<br /> [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004<br /> [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000)<br /> knlGS:0000000000000000<br /> [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0<br /> [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [ 4223.822628] PKRU: 55555554<br /> [ 4223.822628] Call Trace:<br /> [ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0<br /> [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250<br /> [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50<br /> [ 4223.822629] intel_iommu_release_device+0x1f/0x30<br /> [ 4223.822629] iommu_release_device+0x33/0x60<br /> [ 4223.822629] iommu_bus_notifier+0x7f/0x90<br /> [ 4223.822630] blocking_notifier_call_chain+0x60/0x90<br /> [ 4223.822630] device_del+0x2e5/0x420<br /> [ 4223.822630] pci_remove_bus_device+0x70/0x110<br /> [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130<br /> [ 4223.822631] pciehp_disable_slot+0x6b/0x100<br /> [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320<br /> [ 4223.822631] pciehp_ist+0x176/0x180<br /> [ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110<br /> [ 4223.822632] irq_thread_fn+0x19/0x50<br /> [ 4223.822632] irq_thread+0x104/0x190<br /> [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90<br /> [ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0<br /> [ 4223.822633] kthread+0x114/0x130<br /> [ 4223.822633] ? __kthread_cancel_work+0x40/0x40<br /> [ 4223.822633] ret_from_fork+0x1f/0x30<br /> [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP<br /> [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S<br /> OE kernel version xxxx<br /> [ 4223.822634] Hardware name: vendorname xxxx 666-106,<br /> BIOS 01.01.02.03.01 05/15/2023<br /> [ 4223.822634] Call Trace:<br /> [ 4223.822634] <br /> [ 4223.822635] dump_stack+0x6d/0x88<br /> [ 4223.822635] panic+0x101/0x2d0<br /> [ 4223.822635] ? ret_from_fork+0x11/0x30<br /> [ 4223.822635] nmi_panic.cold.14+0xc/0xc<br /> [ 4223.822636] watchdog_overflow_callback.cold.8+0x6d/0x81<br /> [ 4223.822636] __perf_event_overflow+0x4f/0xf0<br /> [ 4223.822636] handle_pmi_common<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921e: fix use-after-free in free_irq()<br /> <br /> From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test<br /> to make sure the shared irq handler should be able to handle the unexpected<br /> event after deregistration. For this case, let&amp;#39;s apply MT76_REMOVED flag to<br /> indicate the device was removed and do not run into the resource access<br /> anymore.<br /> <br /> BUG: KASAN: use-after-free in mt7921_irq_handler+0xd8/0x100 [mt7921e]<br /> Read of size 8 at addr ffff88824a7d3b78 by task rmmod/11115<br /> CPU: 28 PID: 11115 Comm: rmmod Tainted: G W L 5.17.0 #10<br /> Hardware name: Micro-Star International Co., Ltd. MS-7D73/MPG B650I<br /> EDGE WIFI (MS-7D73), BIOS 1.81 01/05/2024<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6f/0xa0<br /> print_address_description.constprop.0+0x1f/0x190<br /> ? mt7921_irq_handler+0xd8/0x100 [mt7921e]<br /> ? mt7921_irq_handler+0xd8/0x100 [mt7921e]<br /> kasan_report.cold+0x7f/0x11b<br /> ? mt7921_irq_handler+0xd8/0x100 [mt7921e]<br /> mt7921_irq_handler+0xd8/0x100 [mt7921e]<br /> free_irq+0x627/0xaa0<br /> devm_free_irq+0x94/0xd0<br /> ? devm_request_any_context_irq+0x160/0x160<br /> ? kobject_put+0x18d/0x4a0<br /> mt7921_pci_remove+0x153/0x190 [mt7921e]<br /> pci_device_remove+0xa2/0x1d0<br /> __device_release_driver+0x346/0x6e0<br /> driver_detach+0x1ef/0x2c0<br /> bus_remove_driver+0xe7/0x2d0<br /> ? __check_object_size+0x57/0x310<br /> pci_unregister_driver+0x26/0x250<br /> __do_sys_delete_module+0x307/0x510<br /> ? free_module+0x6a0/0x6a0<br /> ? fpregs_assert_state_consistent+0x4b/0xb0<br /> ? rcu_read_lock_sched_held+0x10/0x70<br /> ? syscall_enter_from_user_mode+0x20/0x70<br /> ? trace_hardirqs_on+0x1c/0x130<br /> do_syscall_64+0x5c/0x80<br /> ? trace_hardirqs_on_prepare+0x72/0x160<br /> ? do_syscall_64+0x68/0x80<br /> ? trace_hardirqs_on_prepare+0x72/0x160<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae