Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: nuvoton: npcm8xx: Add NULL check in npcm8xx_gpio_fw<br /> <br /> devm_kasprintf() calls can return null pointers on failure.<br /> But the return values were not checked in npcm8xx_gpio_fw().<br /> Add NULL check in npcm8xx_gpio_fw(), to handle kernel NULL<br /> pointer dereference error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix kernel BUG when userfaultfd_move encounters swapcache<br /> <br /> userfaultfd_move() checks whether the PTE entry is present or a<br /> swap entry.<br /> <br /> - If the PTE entry is present, move_present_pte() handles folio<br /> migration by setting:<br /> <br /> src_folio-&gt;index = linear_page_index(dst_vma, dst_addr);<br /> <br /> - If the PTE entry is a swap entry, move_swap_pte() simply copies<br /> the PTE to the new dst_addr.<br /> <br /> This approach is incorrect because, even if the PTE is a swap entry,<br /> it can still reference a folio that remains in the swap cache.<br /> <br /> This creates a race window between steps 2 and 4.<br /> 1. add_to_swap: The folio is added to the swapcache.<br /> 2. try_to_unmap: PTEs are converted to swap entries.<br /> 3. pageout: The folio is written back.<br /> 4. Swapcache is cleared.<br /> If userfaultfd_move() occurs in the window between steps 2 and 4,<br /> after the swap PTE has been moved to the destination, accessing the<br /> destination triggers do_swap_page(), which may locate the folio in<br /> the swapcache. However, since the folio&amp;#39;s index has not been updated<br /> to match the destination VMA, do_swap_page() will detect a mismatch.<br /> <br /> This can result in two critical issues depending on the system<br /> configuration.<br /> <br /> If KSM is disabled, both small and large folios can trigger a BUG<br /> during the add_rmap operation due to:<br /> <br /> page_pgoff(folio, page) != linear_page_index(vma, address)<br /> <br /> [ 13.336953] page: refcount:6 mapcount:1 mapping:00000000f43db19c index:0xffffaf150 pfn:0x4667c<br /> [ 13.337520] head: order:2 mapcount:1 entire_mapcount:0 nr_pages_mapped:1 pincount:0<br /> [ 13.337716] memcg:ffff00000405f000<br /> [ 13.337849] anon flags: 0x3fffc0000020459(locked|uptodate|dirty|owner_priv_1|head|swapbacked|node=0|zone=0|lastcpupid=0xffff)<br /> [ 13.338630] raw: 03fffc0000020459 ffff80008507b538 ffff80008507b538 ffff000006260361<br /> [ 13.338831] raw: 0000000ffffaf150 0000000000004000 0000000600000000 ffff00000405f000<br /> [ 13.339031] head: 03fffc0000020459 ffff80008507b538 ffff80008507b538 ffff000006260361<br /> [ 13.339204] head: 0000000ffffaf150 0000000000004000 0000000600000000 ffff00000405f000<br /> [ 13.339375] head: 03fffc0000000202 fffffdffc0199f01 ffffffff00000000 0000000000000001<br /> [ 13.339546] head: 0000000000000004 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 13.339736] page dumped because: VM_BUG_ON_PAGE(page_pgoff(folio, page) != linear_page_index(vma, address))<br /> [ 13.340190] ------------[ cut here ]------------<br /> [ 13.340316] kernel BUG at mm/rmap.c:1380!<br /> [ 13.340683] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP<br /> [ 13.340969] Modules linked in:<br /> [ 13.341257] CPU: 1 UID: 0 PID: 107 Comm: a.out Not tainted 6.14.0-rc3-gcf42737e247a-dirty #299<br /> [ 13.341470] Hardware name: linux,dummy-virt (DT)<br /> [ 13.341671] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 13.341815] pc : __page_check_anon_rmap+0xa0/0xb0<br /> [ 13.341920] lr : __page_check_anon_rmap+0xa0/0xb0<br /> [ 13.342018] sp : ffff80008752bb20<br /> [ 13.342093] x29: ffff80008752bb20 x28: fffffdffc0199f00 x27: 0000000000000001<br /> [ 13.342404] x26: 0000000000000000 x25: 0000000000000001 x24: 0000000000000001<br /> [ 13.342575] x23: 0000ffffaf0d0000 x22: 0000ffffaf0d0000 x21: fffffdffc0199f00<br /> [ 13.342731] x20: fffffdffc0199f00 x19: ffff000006210700 x18: 00000000ffffffff<br /> [ 13.342881] x17: 6c203d2120296567 x16: 6170202c6f696c6f x15: 662866666f67705f<br /> [ 13.343033] x14: 6567617028454741 x13: 2929737365726464 x12: ffff800083728ab0<br /> [ 13.343183] x11: ffff800082996bf8 x10: 0000000000000fd7 x9 : ffff80008011bc40<br /> [ 13.343351] x8 : 0000000000017fe8 x7 : 00000000fffff000 x6 : ffff8000829eebf8<br /> [ 13.343498] x5 : c0000000fffff000 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 13.343645] x2 : 0000000000000000 x1 : ffff0000062db980 x0 : 000000000000005f<br /> [ 13.343876] Call trace:<br /> [ 13.344045] __page_check_anon_rmap+0xa0/0xb0 (P)<br /> [ 13.344234] folio_add_anon_rmap_ptes+0x22c/0x320<br /> [ 13.344333] do_swap_page+0x1060/0x1400<br /> [ 13.344417] __handl<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/hyperv: Fix address space leak when Hyper-V DRM device is removed<br /> <br /> When a Hyper-V DRM device is probed, the driver allocates MMIO space for<br /> the vram, and maps it cacheable. If the device removed, or in the error<br /> path for device probing, the MMIO space is released but no unmap is done.<br /> Consequently the kernel address space for the mapping is leaked.<br /> <br /> Fix this by adding iounmap() calls in the device removal path, and in the<br /> error path during device probing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched: address a potential NULL pointer dereference in the GRED scheduler.<br /> <br /> If kzalloc in gred_init returns a NULL pointer, the code follows the<br /> error handling path, invoking gred_destroy. This, in turn, calls<br /> gred_offload, where memset could receive a NULL pointer as input,<br /> potentially leading to a kernel crash.<br /> <br /> When table-&gt;opt is NULL in gred_init(), gred_change_table_def()<br /> is not called yet, so it is not necessary to call -&gt;ndo_setup_tc()<br /> in gred_offload().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix memory leak in aRFS after reset<br /> <br /> Fix aRFS (accelerated Receive Flow Steering) structures memory leak by<br /> adding a checker to verify if aRFS memory is already allocated while<br /> configuring VSI. aRFS objects are allocated in two cases:<br /> - as part of VSI initialization (at probe), and<br /> - as part of reset handling<br /> <br /> However, VSI reconfiguration executed during reset involves memory<br /> allocation one more time, without prior releasing already allocated<br /> resources. This led to the memory leak with the following signature:<br /> <br /> [root@os-delivery ~]# cat /sys/kernel/debug/kmemleak<br /> unreferenced object 0xff3c1ca7252e6000 (size 8192):<br /> comm "kworker/0:0", pid 8, jiffies 4296833052<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 0):<br /> [] __kmalloc_cache_noprof+0x275/0x340<br /> [] ice_init_arfs+0x3a/0xe0 [ice]<br /> [] ice_vsi_cfg_def+0x607/0x850 [ice]<br /> [] ice_vsi_setup+0x5b/0x130 [ice]<br /> [] ice_init+0x1c1/0x460 [ice]<br /> [] ice_probe+0x2af/0x520 [ice]<br /> [] local_pci_probe+0x43/0xa0<br /> [] work_for_cpu_fn+0x13/0x20<br /> [] process_one_work+0x179/0x390<br /> [] worker_thread+0x239/0x340<br /> [] kthread+0xcc/0x100<br /> [] ret_from_fork+0x2d/0x50<br /> [] ret_from_fork_asm+0x1a/0x30<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: cancel wiphy_work before freeing wiphy<br /> <br /> A wiphy_work can be queued from the moment the wiphy is allocated and<br /> initialized (i.e. wiphy_new_nm). When a wiphy_work is queued, the<br /> rdev::wiphy_work is getting queued.<br /> <br /> If wiphy_free is called before the rdev::wiphy_work had a chance to run,<br /> the wiphy memory will be freed, and then when it eventally gets to run<br /> it&amp;#39;ll use invalid memory.<br /> <br /> Fix this by canceling the work before freeing the wiphy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: hyperv_fb: Allow graceful removal of framebuffer<br /> <br /> When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to<br /> release the framebuffer forcefully. If this framebuffer is in use it<br /> produce the following WARN and hence this framebuffer is never released.<br /> <br /> [ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40<br /> <br /> [ 44.111289] Call Trace:<br /> [ 44.111290] <br /> [ 44.111291] ? show_regs+0x6c/0x80<br /> [ 44.111295] ? __warn+0x8d/0x150<br /> [ 44.111298] ? framebuffer_release+0x2c/0x40<br /> [ 44.111300] ? report_bug+0x182/0x1b0<br /> [ 44.111303] ? handle_bug+0x6e/0xb0<br /> [ 44.111306] ? exc_invalid_op+0x18/0x80<br /> [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20<br /> [ 44.111311] ? framebuffer_release+0x2c/0x40<br /> [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb]<br /> [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus]<br /> [ 44.111323] device_remove+0x40/0x80<br /> [ 44.111325] device_release_driver_internal+0x20b/0x270<br /> [ 44.111327] ? bus_find_device+0xb3/0xf0<br /> <br /> Fix this by moving the release of framebuffer and assosiated memory<br /> to fb_ops.fb_destroy function, so that framebuffer framework handles<br /> it gracefully.<br /> <br /> While we fix this, also replace manual registrations/unregistration of<br /> framebuffer with devm_register_framebuffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: bnxt: return fail if interface is down in bnxt_queue_mem_alloc()<br /> <br /> The bnxt_queue_mem_alloc() is called to allocate new queue memory when<br /> a queue is restarted.<br /> It internally accesses rx buffer descriptor corresponding to the index.<br /> The rx buffer descriptor is allocated and set when the interface is up<br /> and it&amp;#39;s freed when the interface is down.<br /> So, if queue is restarted if interface is down, kernel panic occurs.<br /> <br /> Splat looks like:<br /> BUG: unable to handle page fault for address: 000000000000b240<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 3 UID: 0 PID: 1563 Comm: ncdevmem2 Not tainted 6.14.0-rc2+ #9 844ddba6e7c459cafd0bf4db9a3198e<br /> Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021<br /> RIP: 0010:bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en]<br /> Code: 41 54 4d 89 c4 4d 69 c0 c0 05 00 00 55 48 89 f5 53 48 89 fb 4c 8d b5 40 05 00 00 48 83 ec 15<br /> RSP: 0018:ffff9dcc83fef9e8 EFLAGS: 00010202<br /> RAX: ffffffffc0457720 RBX: ffff934ed8d40000 RCX: 0000000000000000<br /> RDX: 000000000000001f RSI: ffff934ea508f800 RDI: ffff934ea508f808<br /> RBP: ffff934ea508f800 R08: 000000000000b240 R09: ffff934e84f4b000<br /> R10: ffff9dcc83fefa30 R11: ffff934e84f4b000 R12: 000000000000001f<br /> R13: ffff934ed8d40ac0 R14: ffff934ea508fd40 R15: ffff934e84f4b000<br /> FS: 00007fa73888c740(0000) GS:ffff93559f780000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000000b240 CR3: 0000000145a2e000 CR4: 00000000007506f0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die+0x20/0x70<br /> ? page_fault_oops+0x15a/0x460<br /> ? exc_page_fault+0x6e/0x180<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? __pfx_bnxt_queue_mem_alloc+0x10/0x10 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7]<br /> ? bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7]<br /> netdev_rx_queue_restart+0xc5/0x240<br /> net_devmem_bind_dmabuf_to_queue+0xf8/0x200<br /> netdev_nl_bind_rx_doit+0x3a7/0x450<br /> genl_family_rcv_msg_doit+0xd9/0x130<br /> genl_rcv_msg+0x184/0x2b0<br /> ? __pfx_netdev_nl_bind_rx_doit+0x10/0x10<br /> ? __pfx_genl_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x54/0x100<br /> genl_rcv+0x24/0x40<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mctp: unshare packets when reassembling<br /> <br /> Ensure that the frag_list used for reassembly isn&amp;#39;t shared with other<br /> packets. This avoids incorrect reassembly when packets are cloned, and<br /> prevents a memory leak due to circular references between fragments and<br /> their skb_shared_info.<br /> <br /> The upcoming MCTP-over-USB driver uses skb_clone which can trigger the<br /> problem - other MCTP drivers don&amp;#39;t share SKBs.<br /> <br /> A kunit test is added to reproduce the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd<br /> <br /> After the hci sync command releases l2cap_conn, the hci receive data work<br /> queue references the released l2cap_conn when sending to the upper layer.<br /> Add hci dev lock to the hci receive data work queue to synchronize the two.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954<br /> Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837<br /> <br /> CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: hci1 hci_rx_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:489<br /> kasan_report+0x143/0x180 mm/kasan/report.c:602<br /> l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline]<br /> l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954<br /> l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline]<br /> l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline]<br /> l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817<br /> hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline]<br /> hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3391<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> Allocated by task 5837:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329<br /> kmalloc_noprof include/linux/slab.h:901 [inline]<br /> kzalloc_noprof include/linux/slab.h:1037 [inline]<br /> l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860<br /> l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239<br /> hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]<br /> hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726<br /> hci_event_func net/bluetooth/hci_event.c:7473 [inline]<br /> hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525<br /> hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3391<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> Freed by task 54:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582<br /> poison_slab_object mm/kasan/common.c:247 [inline]<br /> __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264<br /> kasan_slab_free include/linux/kasan.h:233 [inline]<br /> slab_free_hook mm/slub.c:2353 [inline]<br /> slab_free mm/slub.c:4613 [inline]<br /> kfree+0x196/0x430 mm/slub.c:4761<br /> l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235<br /> hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]<br /> hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266<br /> hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603<br /> hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3391<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: bnxt: fix kernel panic in the bnxt_get_queue_stats{rx | tx}<br /> <br /> When qstats-get operation is executed, callbacks of netdev_stats_ops<br /> are called. The bnxt_get_queue_stats{rx | tx} collect per-queue stats<br /> from sw_stats in the rings.<br /> But {rx | tx | cp}_ring are allocated when the interface is up.<br /> So, these rings are not allocated when the interface is down.<br /> <br /> The qstats-get is allowed even if the interface is down. However,<br /> the bnxt_get_queue_stats{rx | tx}() accesses cp_ring and tx_ring<br /> without null check.<br /> So, it needs to avoid accessing rings if the interface is down.<br /> <br /> Reproducer:<br /> ip link set $interface down<br /> ./cli.py --spec netdev.yaml --dump qstats-get<br /> OR<br /> ip link set $interface down<br /> python ./stats.py<br /> <br /> Splat looks like:<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 1680fa067 P4D 1680fa067 PUD 16be3b067 PMD 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 UID: 0 PID: 1495 Comm: python3 Not tainted 6.14.0-rc4+ #32 5cd0f999d5a15c574ac72b3e4b907341<br /> Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021<br /> RIP: 0010:bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en]<br /> Code: c6 87 b5 18 00 00 02 eb a2 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 01<br /> RSP: 0018:ffffabef43cdb7e0 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffffffffc04c8710 RCX: 0000000000000000<br /> RDX: ffffabef43cdb858 RSI: 0000000000000000 RDI: ffff8d504e850000<br /> RBP: ffff8d506c9f9c00 R08: 0000000000000004 R09: ffff8d506bcd901c<br /> R10: 0000000000000015 R11: ffff8d506bcd9000 R12: 0000000000000000<br /> R13: ffffabef43cdb8c0 R14: ffff8d504e850000 R15: 0000000000000000<br /> FS: 00007f2c5462b080(0000) GS:ffff8d575f600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000167fd0000 CR4: 00000000007506f0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die+0x20/0x70<br /> ? page_fault_oops+0x15a/0x460<br /> ? sched_balance_find_src_group+0x58d/0xd10<br /> ? exc_page_fault+0x6e/0x180<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en cdd546fd48563c280cfd30e9647efa420db07bf1]<br /> netdev_nl_stats_by_netdev+0x2b1/0x4e0<br /> ? xas_load+0x9/0xb0<br /> ? xas_find+0x183/0x1d0<br /> ? xa_find+0x8b/0xe0<br /> netdev_nl_qstats_get_dumpit+0xbf/0x1e0<br /> genl_dumpit+0x31/0x90<br /> netlink_dump+0x1a8/0x360

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix slab-use-after-free on hdcp_work<br /> <br /> [Why]<br /> A slab-use-after-free is reported when HDCP is destroyed but the<br /> property_validate_dwork queue is still running.<br /> <br /> [How]<br /> Cancel the delayed work when destroying workqueue.<br /> <br /> (cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)