{"schema_version":"1.7.2","id":"OESA-2025-1286","modified":"2025-03-14T15:46:39Z","published":"2025-03-14T15:46:39Z","upstream":["CVE-2023-52926","CVE-2024-41935","CVE-2024-47143","CVE-2024-47809","CVE-2024-48881","CVE-2024-53141","CVE-2024-53148","CVE-2024-53156","CVE-2024-53176","CVE-2024-53177","CVE-2024-53178","CVE-2024-53181","CVE-2024-53185","CVE-2024-53210","CVE-2024-53214","CVE-2024-53216","CVE-2024-53233","CVE-2024-54456","CVE-2024-56531","CVE-2024-56533","CVE-2024-56539","CVE-2024-56545","CVE-2024-56551","CVE-2024-56558","CVE-2024-56566","CVE-2024-56573","CVE-2024-56574","CVE-2024-56576","CVE-2024-56577","CVE-2024-56579","CVE-2024-56587","CVE-2024-56593","CVE-2024-56600","CVE-2024-56601","CVE-2024-56602","CVE-2024-56603","CVE-2024-56606","CVE-2024-56625","CVE-2024-56628","CVE-2024-56636","CVE-2024-56637","CVE-2024-56643","CVE-2024-56644","CVE-2024-56645","CVE-2024-56650","CVE-2024-56651","CVE-2024-56678","CVE-2024-56689","CVE-2024-56704","CVE-2024-56707","CVE-2024-56723","CVE-2024-56724","CVE-2024-56725","CVE-2024-56727","CVE-2024-56746","CVE-2024-56751","CVE-2024-56754","CVE-2024-56774","CVE-2024-56783","CVE-2024-56785","CVE-2024-57838","CVE-2024-57876","CVE-2024-57899","CVE-2024-57981","CVE-2024-58001","CVE-2024-58070","CVE-2025-21729","CVE-2025-21732","CVE-2025-21736","CVE-2025-21743","CVE-2025-21767","CVE-2025-21776","CVE-2025-21782","CVE-2025-21783","CVE-2025-21789","CVE-2025-21795","CVE-2025-21796","CVE-2025-21814","CVE-2025-21817"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nIORING_OP_READ did not correctly consume the provided buffer list when\nread i/o returned \u0026lt; 0 (except for -EAGAIN and -EIOCBQUEUED return).\nThis can lead to a potential use-after-free when the completion via\nio_rw_done runs at separate context.(CVE-2023-52926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to shrink read extent node in batches\n\nWe use rwlock to protect core structure data of extent tree during\nits shrink, however, if there is a huge number of extent nodes in\nextent tree, during shrink of extent tree, it may hold rwlock for\na very long time, which may trigger kernel hang issue.\n\nThis patch fixes to shrink read extent node in batches, so that,\ncritical region of the rwlock can be shrunk to avoid its extreme\nlong time hold.(CVE-2024-41935)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndma-debug: fix a possible deadlock on radix_lock\n\nradix_lock() shouldn\u0026apos;t be held while holding dma_hash_entry[idx].lock\notherwise, there\u0026apos;s a possible deadlock scenario when\ndma debug API is called holding rq_lock():\n\nCPU0                   CPU1                       CPU2\ndma_free_attrs()\ncheck_unmap()          add_dma_entry()            __schedule() //out\n                                                  (A) rq_lock()\nget_hash_bucket()\n(A) dma_entry_hash\n                                                  check_sync()\n                       (A) radix_lock()           (W) dma_entry_hash\ndma_entry_free()\n(W) radix_lock()\n                       // CPU2\u0026apos;s one\n                       (W) rq_lock()\n\nCPU1 situation can happen when it extending radix tree and\nit tries to wake up kswapd via wake_all_kswapd().\n\nCPU2 situation can happen while perf_event_task_sched_out()\n(i.e. dma sync operation is called while deleting perf_event using\n etm and etr tmc which are Arm Coresight hwtracing driver backends).\n\nTo remove this possible situation, call dma_entry_free() after\nput_hash_bucket() in check_unmap().(CVE-2024-47143)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: fix possible lkb_resource null dereference\n\nThis patch fixes a possible null pointer dereference when this function is\ncalled from request_lock() as lkb-\u0026gt;lkb_resource is not assigned yet,\nonly after validate_lock_args() by calling attach_lkb(). Another issue\nis that a resource name could be a non printable bytearray and we cannot\nassume to be ASCII coded.\n\nThe log functionality is probably never being hit when DLM is used in\nnormal way and no debug logging is enabled. The null pointer dereference\ncan only occur on a new created lkb that does not have the resource\nassigned yet, it probably never hits the null pointer dereference but we\nshould be sure that other changes might not change this behaviour and we\nactually can hit the mentioned null pointer dereference.\n\nIn this patch we just drop the printout of the resource name, the lkb id\nis enough to make a possible connection to a resource name if this\nexists.(CVE-2024-47809)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: revert replacing IS_ERR_OR_NULL with IS_ERR again\n\nCommit 028ddcac477b (\u0026quot;bcache: Remove unnecessary NULL point check in\nnode allocations\u0026quot;) leads a NULL pointer deference in cache_set_flush().\n\n1721         if (!IS_ERR_OR_NULL(c-\u0026gt;root))\n1722                 list_add(\u0026amp;c-\u0026gt;root-\u0026gt;list, \u0026amp;c-\u0026gt;btree_cache);\n\n\u0026gt;From the above code in cache_set_flush(), if previous registration code\nfails before allocating c-\u0026gt;root, it is possible c-\u0026gt;root is NULL as what\nit is initialized. __bch_btree_node_alloc() never returns NULL but\nc-\u0026gt;root is possible to be NULL at above line 1721.\n\nThis patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.(CVE-2024-48881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: add missing range check in bitmap_ip_uadt\n\nWhen tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,\nthe values of ip and ip_to are slightly swapped. Therefore, the range check\nfor ip should be done later, but this part is missing and it seems that the\nvulnerability occurs.\n\nSo we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: Flush partial mappings in error case\n\nIf some remap_pfn_range() calls succeeded before one failed, we still have\nbuffer pages mapped into the userspace page tables when we drop the buffer\nreference with comedi_buf_map_put(bm). The userspace mappings are only\ncleaned up later in the mmap error path.\n\nFix it by explicitly flushing all mappings in our VMA on the error path.\n\nSee commit 79a61cc3fc04 (\u0026quot;mm: avoid leaving partial pfn mappings around in\nerror case\u0026quot;).(CVE-2024-53148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()\n\nI found the following bug in my fuzzer:\n\n  UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51\n  index 255 is out of range for type \u0026apos;htc_endpoint [22]\u0026apos;\n  CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n  Workqueue: events request_firmware_work_func\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x180/0x1b0\n   __ubsan_handle_out_of_bounds+0xd4/0x130\n   htc_issue_send.constprop.0+0x20c/0x230\n   ? _raw_spin_unlock_irqrestore+0x3c/0x70\n   ath9k_wmi_cmd+0x41d/0x610\n   ? mark_held_locks+0x9f/0xe0\n   ...\n\nSince this bug has been confirmed to be caused by insufficient verification\nof conn_rsp_epid, I think it would be appropriate to add a range check for\nconn_rsp_epid to htc_connect_service() to prevent the bug from occurring.(CVE-2024-53156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: During unmount, ensure all cached dir instances drop their dentry\n\nThe unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can\nrace with various cached directory operations, which ultimately results\nin dentries not being dropped and these kernel BUGs:\n\nBUG: Dentry ffff88814f37e358{i=1000000000080,n=/}  still in use (2) [unmount of cifs cifs]\nVFS: Busy inodes after unmount of cifs (cifs)\n------------[ cut here ]------------\nkernel BUG at fs/super.c:661!\n\nThis happens when a cfid is in the process of being cleaned up when, and\nhas been removed from the cfids-\u0026gt;entries list, including:\n\n- Receiving a lease break from the server\n- Server reconnection triggers invalidate_all_cached_dirs(), which\n  removes all the cfids from the list\n- The laundromat thread decides to expire an old cfid.\n\nTo solve these problems, dropping the dentry is done in queued work done\nin a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()\nflushes that workqueue after it drops all the dentries of which it\u0026apos;s\naware. This is a global workqueue (rather than scoped to a mount), but\nthe queued work is minimal.\n\nThe final cleanup work for cleaning up a cfid is performed via work\nqueued in the serverclose_wq workqueue; this is done separate from\ndropping the dentries so that close_all_cached_dirs() doesn\u0026apos;t block on\nany server operations.\n\nBoth of these queued works expect to invoked with a cfid reference and\na tcon reference to avoid those objects from being freed while the work\nis ongoing.\n\nWhile we\u0026apos;re here, add proper locking to close_all_cached_dirs(), and\nlocking around the freeing of cfid-\u0026gt;dentry.(CVE-2024-53176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: prevent use-after-free due to open_cached_dir error paths\n\nIf open_cached_dir() encounters an error parsing the lease from the\nserver, the error handling may race with receiving a lease break,\nresulting in open_cached_dir() freeing the cfid while the queued work is\npending.\n\nUpdate open_cached_dir() to drop refs rather than directly freeing the\ncfid.\n\nHave cached_dir_lease_break(), cfids_laundromat_worker(), and\ninvalidate_all_cached_dirs() clear has_lease immediately while still\nholding cfids-\u0026gt;cfid_list_lock, and then use this to also simplify the\nreference counting in cfids_laundromat_worker() and\ninvalidate_all_cached_dirs().\n\nFixes this KASAN splat (which manually injects an error and lease break\nin open_cached_dir()):\n\n==================================================================\nBUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0\nRead of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65\n\nCPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\nWorkqueue: cifsiod smb2_cached_lease_break\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x77/0xb0\n print_report+0xce/0x660\n kasan_report+0xd3/0x110\n smb2_cached_lease_break+0x27/0xb0\n process_one_work+0x50a/0xc50\n worker_thread+0x2ba/0x530\n kthread+0x17c/0x1c0\n ret_from_fork+0x34/0x60\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 2464:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n open_cached_dir+0xa7d/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 2464:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x51/0x70\n kfree+0x174/0x520\n open_cached_dir+0x97f/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x33/0x60\n __kasan_record_aux_stack+0xad/0xc0\n insert_work+0x32/0x100\n __queue_work+0x5c9/0x870\n queue_work_on+0x82/0x90\n open_cached_dir+0x1369/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe buggy address belongs to the object at ffff88811cc24c00\n which belongs to the cache kmalloc-1k of size 1024\nThe buggy address is located 16 bytes inside of\n freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)(CVE-2024-53177)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: Don\u0026apos;t leak cfid when reconnect races with open_cached_dir\n\nopen_cached_dir() may either race with the tcon reconnection even before\ncompound_send_recv() or directly trigger a reconnection via\nSMB2_open_init() or SMB_query_info_init().\n\nThe reconnection process invokes invalidate_all_cached_dirs() via\ncifs_mark_open_files_invalid(), which removes all cfids from the\ncfids-\u0026gt;entries list but doesn\u0026apos;t drop a ref if has_lease isn\u0026apos;t true. This\nresults in the currently-being-constructed cfid not being on the list,\nbut still having a refcount of 2. It leaks if returned from\nopen_cached_dir().\n\nFix this by setting cfid-\u0026gt;has_lease when the ref is actually taken; the\ncfid will not be used by other threads until it has a valid time.\n\nAddresses these kmemleaks:\n\nunreferenced object 0xffff8881090c4000 (size 1024):\n  comm \u0026quot;bash\u0026quot;, pid 1860, jiffies 4295126592\n  hex dump (first 32 bytes):\n    00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de  ........\u0026quot;.......\n    00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff  ..E\u0026quot;......O.....\n  backtrace (crc 6f58c20f):\n    [\u0026lt;ffffffff8b895a1e\u0026gt;] __kmalloc_cache_noprof+0x2be/0x350\n    [\u0026lt;ffffffff8bda06e3\u0026gt;] open_cached_dir+0x993/0x1fb0\n    [\u0026lt;ffffffff8bdaa750\u0026gt;] cifs_readdir+0x15a0/0x1d50\n    [\u0026lt;ffffffff8b9a853f\u0026gt;] iterate_dir+0x28f/0x4b0\n    [\u0026lt;ffffffff8b9a9aed\u0026gt;] __x64_sys_getdents64+0xfd/0x200\n    [\u0026lt;ffffffff8cf6da05\u0026gt;] do_syscall_64+0x95/0x1a0\n    [\u0026lt;ffffffff8d00012f\u0026gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e\nunreferenced object 0xffff8881044fdcf8 (size 8):\n  comm \u0026quot;bash\u0026quot;, pid 1860, jiffies 4295126592\n  hex dump (first 8 bytes):\n    00 cc cc cc cc cc cc cc                          ........\n  backtrace (crc 10c106a9):\n    [\u0026lt;ffffffff8b89a3d3\u0026gt;] __kmalloc_node_track_caller_noprof+0x363/0x480\n    [\u0026lt;ffffffff8b7d7256\u0026gt;] kstrdup+0x36/0x60\n    [\u0026lt;ffffffff8bda0700\u0026gt;] open_cached_dir+0x9b0/0x1fb0\n    [\u0026lt;ffffffff8bdaa750\u0026gt;] cifs_readdir+0x15a0/0x1d50\n    [\u0026lt;ffffffff8b9a853f\u0026gt;] iterate_dir+0x28f/0x4b0\n    [\u0026lt;ffffffff8b9a9aed\u0026gt;] __x64_sys_getdents64+0xfd/0x200\n    [\u0026lt;ffffffff8cf6da05\u0026gt;] do_syscall_64+0x95/0x1a0\n    [\u0026lt;ffffffff8d00012f\u0026gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nAnd addresses these BUG splats when unmounting the SMB filesystem:\n\nBUG: Dentry ffff888140590ba0{i=1000000000080,n=/}  still in use (2) [unmount of cifs cifs]\nWARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100\nModules linked in:\nCPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\nRIP: 0010:umount_check+0xd0/0x100\nCode: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff \u0026lt;0f\u0026gt; 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41\nRSP: 0018:ffff88811cc27978 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40\nRBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3\nR10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08\nR13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0\nFS:  00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n d_walk+0x6a/0x530\n shrink_dcache_for_umount+0x6a/0x200\n generic_shutdown_super+0x52/0x2a0\n kill_anon_super+0x22/0x40\n cifs_kill_sb+0x159/0x1e0\n deactivate_locked_super+0x66/0xe0\n cleanup_mnt+0x140/0x210\n task_work_run+0xfb/0x170\n syscall_exit_to_user_mode+0x29f/0x2b0\n do_syscall_64+0xa1/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f23bfb93ae7\nCode: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 \n---truncated---(CVE-2024-53178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: vector: Do not use drvdata in release\n\nThe drvdata is not available in release. Let\u0026apos;s just use container_of()\nto get the vector_device instance. Otherwise, removing a vector device\nwill result in a crash:\n\nRIP: 0033:vector_device_release+0xf/0x50\nRSP: 00000000e187bc40  EFLAGS: 00010202\nRAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0\nRDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000\nRBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70\nR10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028\nR13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6\nKernel panic - not syncing: Segfault with no mm\nCPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1\nWorkqueue: events mc_work_proc\nStack:\n 60028f61 623ae028 e187bc80 60276fcd\n 6220b9c0 603f5820 623ae028 00000000\n e187bcb0 603a2bcd 623ae000 62370010\nCall Trace:\n [\u0026lt;60028f61\u0026gt;] ? vector_device_release+0x0/0x50\n [\u0026lt;60276fcd\u0026gt;] device_release+0x70/0xba\n [\u0026lt;603a2bcd\u0026gt;] kobject_put+0xba/0xe7\n [\u0026lt;60277265\u0026gt;] put_device+0x19/0x1c\n [\u0026lt;60281266\u0026gt;] platform_device_put+0x26/0x29\n [\u0026lt;60281e5f\u0026gt;] platform_device_unregister+0x2c/0x2e\n [\u0026lt;60029422\u0026gt;] vector_remove+0x52/0x58\n [\u0026lt;60031316\u0026gt;] ? mconsole_reply+0x0/0x50\n [\u0026lt;600310c8\u0026gt;] mconsole_remove+0x160/0x1cc\n [\u0026lt;603b19f4\u0026gt;] ? strlen+0x0/0x15\n [\u0026lt;60066611\u0026gt;] ? __dequeue_entity+0x1a9/0x206\n [\u0026lt;600666a7\u0026gt;] ? set_next_entity+0x39/0x63\n [\u0026lt;6006666e\u0026gt;] ? set_next_entity+0x0/0x63\n [\u0026lt;60038fa6\u0026gt;] ? um_set_signals+0x0/0x43\n [\u0026lt;6003070c\u0026gt;] mc_work_proc+0x77/0x91\n [\u0026lt;60057664\u0026gt;] process_scheduled_works+0x1b3/0x2dd\n [\u0026lt;60055f32\u0026gt;] ? assign_work+0x0/0x58\n [\u0026lt;60057f0a\u0026gt;] worker_thread+0x1e9/0x293\n [\u0026lt;6005406f\u0026gt;] ? set_pf_worker+0x0/0x64\n [\u0026lt;6005d65d\u0026gt;] ? arch_local_irq_save+0x0/0x2d\n [\u0026lt;6005d748\u0026gt;] ? kthread_exit+0x0/0x3a\n [\u0026lt;60057d21\u0026gt;] ? worker_thread+0x0/0x293\n [\u0026lt;6005dbf1\u0026gt;] kthread+0x126/0x12b\n [\u0026lt;600219c5\u0026gt;] new_thread_handler+0x85/0xb6(CVE-2024-53181)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix NULL ptr deref in crypto_aead_setkey()\n\nNeither SMB3.0 or SMB3.02 supports encryption negotiate context, so\nwhen SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,\nthe client uses AES-128-CCM as the default cipher.  See MS-SMB2\n3.3.5.4.\n\nCommit b0abcd65ec54 (\u0026quot;smb: client: fix UAF in async decryption\u0026quot;) added\na @server-\u0026gt;cipher_type check to conditionally call\nsmb3_crypto_aead_allocate(), but that check would always be false as\n@server-\u0026gt;cipher_type is unset for SMB3.02.\n\nFix the following KASAN splat by setting @server-\u0026gt;cipher_type for\nSMB3.02 as well.\n\nmount.cifs //srv/share /mnt -o vers=3.02,seal,...\n\nBUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130\nRead of size 8 at addr 0000000000000020 by task mount.cifs/1095\nCPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41\n04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5d/0x80\n ? crypto_aead_setkey+0x2c/0x130\n kasan_report+0xda/0x110\n ? crypto_aead_setkey+0x2c/0x130\n crypto_aead_setkey+0x2c/0x130\n crypt_message+0x258/0xec0 [cifs]\n ? __asan_memset+0x23/0x50\n ? __pfx_crypt_message+0x10/0x10 [cifs]\n ? mark_lock+0xb0/0x6a0\n ? hlock_class+0x32/0xb0\n ? mark_lock+0xb0/0x6a0\n smb3_init_transform_rq+0x352/0x3f0 [cifs]\n ? lock_acquire.part.0+0xf4/0x2a0\n smb_send_rqst+0x144/0x230 [cifs]\n ? __pfx_smb_send_rqst+0x10/0x10 [cifs]\n ? hlock_class+0x32/0xb0\n ? smb2_setup_request+0x225/0x3a0 [cifs]\n ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs]\n compound_send_recv+0x59b/0x1140 [cifs]\n ? __pfx_compound_send_recv+0x10/0x10 [cifs]\n ? __create_object+0x5e/0x90\n ? hlock_class+0x32/0xb0\n ? do_raw_spin_unlock+0x9a/0xf0\n cifs_send_recv+0x23/0x30 [cifs]\n SMB2_tcon+0x3ec/0xb30 [cifs]\n ? __pfx_SMB2_tcon+0x10/0x10 [cifs]\n ? lock_acquire.part.0+0xf4/0x2a0\n ? __pfx_lock_release+0x10/0x10\n ? do_raw_spin_trylock+0xc6/0x120\n ? lock_acquire+0x3f/0x90\n ? _get_xid+0x16/0xd0 [cifs]\n ? __pfx_SMB2_tcon+0x10/0x10 [cifs]\n ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs]\n cifs_get_smb_ses+0xcdd/0x10a0 [cifs]\n ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs]\n ? cifs_get_tcp_session+0xaa0/0xca0 [cifs]\n cifs_mount_get_session+0x8a/0x210 [cifs]\n dfs_mount_share+0x1b0/0x11d0 [cifs]\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_dfs_mount_share+0x10/0x10 [cifs]\n ? lock_acquire.part.0+0xf4/0x2a0\n ? find_held_lock+0x8a/0xa0\n ? hlock_class+0x32/0xb0\n ? lock_release+0x203/0x5d0\n cifs_mount+0xb3/0x3d0 [cifs]\n ? do_raw_spin_trylock+0xc6/0x120\n ? __pfx_cifs_mount+0x10/0x10 [cifs]\n ? lock_acquire+0x3f/0x90\n ? find_nls+0x16/0xa0\n ? smb3_update_mnt_flags+0x372/0x3b0 [cifs]\n cifs_smb3_do_mount+0x1e2/0xc80 [cifs]\n ? __pfx_vfs_parse_fs_string+0x10/0x10\n ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs]\n smb3_get_tree+0x1bf/0x330 [cifs]\n vfs_get_tree+0x4a/0x160\n path_mount+0x3c1/0xfb0\n ? kasan_quarantine_put+0xc7/0x1d0\n ? __pfx_path_mount+0x10/0x10\n ? kmem_cache_free+0x118/0x3e0\n ? user_path_at+0x74/0xa0\n __x64_sys_mount+0x1a6/0x1e0\n ? __pfx___x64_sys_mount+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()\n\nPassing MSG_PEEK flag to skb_recv_datagram() increments skb refcount\n(skb-\u0026gt;users) and iucv_sock_recvmsg() does not decrement skb refcount\nat exit.\nThis results in skb memory leak in skb_queue_purge() and WARN_ON in\niucv_sock_destruct() during socket close. To fix this decrease\nskb refcount by one if MSG_PEEK is set in order to prevent memory\nleak and WARN_ON.\n\nWARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]\nCPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G        W          6.10.0-rc7 #1\nHardware name: IBM 3931 A01 704 (z/VM 7.3.0)\nCall Trace:\n        [\u0026lt;001587c682c4aa98\u0026gt;] iucv_sock_destruct+0x148/0x1a0 [af_iucv]\n        [\u0026lt;001587c682c4a9d0\u0026gt;] iucv_sock_destruct+0x80/0x1a0 [af_iucv]\n        [\u0026lt;001587c704117a32\u0026gt;] __sk_destruct+0x52/0x550\n        [\u0026lt;001587c704104a54\u0026gt;] __sock_release+0xa4/0x230\n        [\u0026lt;001587c704104c0c\u0026gt;] sock_close+0x2c/0x40\n        [\u0026lt;001587c702c5f5a8\u0026gt;] __fput+0x2e8/0x970\n        [\u0026lt;001587c7024148c4\u0026gt;] task_work_run+0x1c4/0x2c0\n        [\u0026lt;001587c7023b0716\u0026gt;] do_exit+0x996/0x1050\n        [\u0026lt;001587c7023b13aa\u0026gt;] do_group_exit+0x13a/0x360\n        [\u0026lt;001587c7023b1626\u0026gt;] __s390x_sys_exit_group+0x56/0x60\n        [\u0026lt;001587c7022bccca\u0026gt;] do_syscall+0x27a/0x380\n        [\u0026lt;001587c7049a6a0c\u0026gt;] __do_syscall+0x9c/0x160\n        [\u0026lt;001587c7049ce8a8\u0026gt;] system_call+0x70/0x98\n        Last Breaking-Event-Address:\n        [\u0026lt;001587c682c4a9d4\u0026gt;] iucv_sock_destruct+0x84/0x1a0 [af_iucv](CVE-2024-53210)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/pci: Properly hide first-in-list PCIe extended capability\n\nThere are cases where a PCIe extended capability should be hidden from\nthe user. For example, an unknown capability (i.e., capability with ID\ngreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally\nchosen to be hidden from the user.\n\nHiding a capability is done by virtualizing and modifying the \u0026apos;Next\nCapability Offset\u0026apos; field of the previous capability so it points to the\ncapability after the one that should be hidden.\n\nThe special case where the first capability in the list should be hidden\nis handled differently because there is no previous capability that can\nbe modified. In this case, the capability ID and version are zeroed\nwhile leaving the next pointer intact. This hides the capability and\nleaves an anchor for the rest of the capability list.\n\nHowever, today, hiding the first capability in the list is not done\nproperly if the capability is unknown, as struct\nvfio_pci_core_device-\u0026gt;pci_config_map is set to the capability ID during\ninitialization but the capability ID is not properly checked later when\nused in vfio_config_do_rw(). This leads to the following warning [1] and\nto an out-of-bounds access to ecap_perms array.\n\nFix it by checking cap_id in vfio_config_do_rw(), and if it is greater\nthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct\nread only access instead of the ecap_perms array.\n\nNote that this is safe since the above is the only case where cap_id can\nexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which\nare already checked before).\n\n[1]\n\nWARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\nCPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1\n(snip)\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x69/0x80\n ? __warn+0x8d/0x140\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? report_bug+0x18f/0x1a0\n ? handle_bug+0x63/0xa0\n ? exc_invalid_op+0x19/0x70\n ? asm_exc_invalid_op+0x1b/0x20\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]\n vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]\n vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]\n vfio_device_fops_read+0x27/0x40 [vfio]\n vfs_read+0xbd/0x340\n ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]\n ? __rseq_handle_notify_resume+0xa4/0x4b0\n __x64_sys_pread64+0x96/0xc0\n x64_sys_call+0x1c3d/0x20d0\n do_syscall_64+0x4d/0x120\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: release svc_expkey/svc_export with rcu_work\n\nThe last reference for `cache_head` can be reduced to zero in `c_show`\nand `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,\n`svc_export_put` and `expkey_put` will be invoked, leading to two\nissues:\n\n1. The `svc_export_put` will directly free ex_uuid. However,\n   `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can\n   trigger a use-after-free issue, shown below.\n\n   ==================================================================\n   BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd]\n   Read of size 1 at addr ff11000010fdc120 by task cat/870\n\n   CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1\n   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n   1.16.1-2.fc37 04/01/2014\n   Call Trace:\n    \u0026lt;TASK\u0026gt;\n    dump_stack_lvl+0x53/0x70\n    print_address_description.constprop.0+0x2c/0x3a0\n    print_report+0xb9/0x280\n    kasan_report+0xae/0xe0\n    svc_export_show+0x362/0x430 [nfsd]\n    c_show+0x161/0x390 [sunrpc]\n    seq_read_iter+0x589/0x770\n    seq_read+0x1e5/0x270\n    proc_reg_read+0xe1/0x140\n    vfs_read+0x125/0x530\n    ksys_read+0xc1/0x160\n    do_syscall_64+0x5f/0x170\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n   Allocated by task 830:\n    kasan_save_stack+0x20/0x40\n    kasan_save_track+0x14/0x30\n    __kasan_kmalloc+0x8f/0xa0\n    __kmalloc_node_track_caller_noprof+0x1bc/0x400\n    kmemdup_noprof+0x22/0x50\n    svc_export_parse+0x8a9/0xb80 [nfsd]\n    cache_do_downcall+0x71/0xa0 [sunrpc]\n    cache_write_procfs+0x8e/0xd0 [sunrpc]\n    proc_reg_write+0xe1/0x140\n    vfs_write+0x1a5/0x6d0\n    ksys_write+0xc1/0x160\n    do_syscall_64+0x5f/0x170\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n   Freed by task 868:\n    kasan_save_stack+0x20/0x40\n    kasan_save_track+0x14/0x30\n    kasan_save_free_info+0x3b/0x60\n    __kasan_slab_free+0x37/0x50\n    kfree+0xf3/0x3e0\n    svc_export_put+0x87/0xb0 [nfsd]\n    cache_purge+0x17f/0x1f0 [sunrpc]\n    nfsd_destroy_serv+0x226/0x2d0 [nfsd]\n    nfsd_svc+0x125/0x1e0 [nfsd]\n    write_threads+0x16a/0x2a0 [nfsd]\n    nfsctl_transaction_write+0x74/0xa0 [nfsd]\n    vfs_write+0x1a5/0x6d0\n    ksys_write+0xc1/0x160\n    do_syscall_64+0x5f/0x170\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.\n   However, `svc_export_put`/`expkey_put` will call path_put, which\n   subsequently triggers a sleeping operation due to the following\n   `dput`.\n\n   =============================\n   WARNING: suspicious RCU usage\n   5.10.0-dirty #141 Not tainted\n   -----------------------------\n   ...\n   Call Trace:\n   dump_stack+0x9a/0xd0\n   ___might_sleep+0x231/0x240\n   dput+0x39/0x600\n   path_put+0x1b/0x30\n   svc_export_put+0x17/0x80\n   e_show+0x1c9/0x200\n   seq_read_iter+0x63f/0x7c0\n   seq_read+0x226/0x2d0\n   vfs_read+0x113/0x2c0\n   ksys_read+0xc9/0x170\n   do_syscall_64+0x33/0x40\n   entry_SYSCALL_64_after_hwframe+0x67/0xd1\n\nFix these issues by using `rcu_work` to help release\n`svc_expkey`/`svc_export`. This approach allows for an asynchronous\ncontext to invoke `path_put` and also facilitates the freeing of\n`uuid/exp/key` after an RCU grace period.(CVE-2024-53216)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nunicode: Fix utf8_load() error path\n\nutf8_load() requests the symbol \u0026quot;utf8_data_table\u0026quot; and then checks if the\nrequested UTF-8 version is supported. If it\u0026apos;s unsupported, it tries to\nput the data table using symbol_put(). If an unsupported version is\nrequested, symbol_put() fails like this:\n\n kernel BUG at kernel/module/main.c:786!\n RIP: 0010:__symbol_put+0x93/0xb0\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __die_body.cold+0x19/0x27\n  ? die+0x2e/0x50\n  ? do_trap+0xca/0x110\n  ? do_error_trap+0x65/0x80\n  ? __symbol_put+0x93/0xb0\n  ? exc_invalid_op+0x51/0x70\n  ? __symbol_put+0x93/0xb0\n  ? asm_exc_invalid_op+0x1a/0x20\n  ? __pfx_cmp_name+0x10/0x10\n  ? __symbol_put+0x93/0xb0\n  ? __symbol_put+0x62/0xb0\n  utf8_load+0xf8/0x150\n\nThat happens because symbol_put() expects the unique string that\nidentify the symbol, instead of a pointer to the loaded symbol. Fix that\nby using such string.(CVE-2024-53233)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client()\n\nname is char[64] where the size of clnt-\u0026gt;cl_program-\u0026gt;name remains\nunknown. Invoking strcat() directly will also lead to potential buffer\noverflow. Change them to strscpy() and strncat() to fix potential\nissues.(CVE-2024-54456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting.  OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long.  It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed().  This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.\n\nThis patch also splits the code to the disconnect and the free phases;\nthe former is called immediately at the USB disconnect callback while\nthe latter is called from the card destructor.(CVE-2024-56531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usx2y: Use snd_card_free_when_closed() at disconnection\n\nThe USB disconnect callback is supposed to be short and not too-long\nwaiting.  OTOH, the current code uses snd_card_free() at\ndisconnection, but this waits for the close of all used fds, hence it\ncan take long.  It eventually blocks the upper layer USB ioctls, which\nmay trigger a soft lockup.\n\nAn easy workaround is to replace snd_card_free() with\nsnd_card_free_when_closed().  This variant returns immediately while\nthe release of resources is done asynchronously by the card device\nrelease at the last close.(CVE-2024-56533)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()\n\nReplace one-element array with a flexible-array member in `struct\nmwifiex_ie_types_wildcard_ssid_params` to fix the following warning\non a MT8173 Chromebook (mt8173-elm-hana):\n\n[  356.775250] ------------[ cut here ]------------\n[  356.784543] memcpy: detected field-spanning write (size 6) of single field \u0026quot;wildcard_ssid_tlv-\u0026gt;ssid\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)\n[  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]\n\nThe \u0026quot;(size 6)\u0026quot; above is exactly the length of the SSID of the network\nthis device was connected to. The source of the warning looks like:\n\n    ssid_len = user_scan_in-\u0026gt;ssid_list[i].ssid_len;\n    [...]\n    memcpy(wildcard_ssid_tlv-\u0026gt;ssid,\n           user_scan_in-\u0026gt;ssid_list[i].ssid, ssid_len);\n\nThere is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this\nstruct, but it already didn\u0026apos;t account for the size of the one-element\narray, so it doesn\u0026apos;t need to be changed.(CVE-2024-56539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hyperv: streamline driver probe to avoid devres issues\n\nIt was found that unloading \u0026apos;hid_hyperv\u0026apos; module results in a devres\ncomplaint:\n\n ...\n hv_vmbus: unregistering driver hid_hyperv\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? devres_release_group+0x1f2/0x2c0\n  ? __warn+0xd1/0x1c0\n  ? devres_release_group+0x1f2/0x2c0\n  ? report_bug+0x32a/0x3c0\n  ? handle_bug+0x53/0xa0\n  ? exc_invalid_op+0x18/0x50\n  ? asm_exc_invalid_op+0x1a/0x20\n  ? devres_release_group+0x1f2/0x2c0\n  ? devres_release_group+0x90/0x2c0\n  ? rcu_is_watching+0x15/0xb0\n  ? __pfx_devres_release_group+0x10/0x10\n  hid_device_remove+0xf5/0x220\n  device_release_driver_internal+0x371/0x540\n  ? klist_put+0xf3/0x170\n  bus_remove_device+0x1f1/0x3f0\n  device_del+0x33f/0x8c0\n  ? __pfx_device_del+0x10/0x10\n  ? cleanup_srcu_struct+0x337/0x500\n  hid_destroy_device+0xc8/0x130\n  mousevsc_remove+0xd2/0x1d0 [hid_hyperv]\n  device_release_driver_internal+0x371/0x540\n  driver_detach+0xc5/0x180\n  bus_remove_driver+0x11e/0x2a0\n  ? __mutex_unlock_slowpath+0x160/0x5e0\n  vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus]\n  ...\n\nAnd the issue seems to be that the corresponding devres group is not\nallocated. Normally, devres_open_group() is called from\n__hid_device_probe() but Hyper-V HID driver overrides \u0026apos;hid_dev-\u0026gt;driver\u0026apos;\nwith \u0026apos;mousevsc_hid_driver\u0026apos; stub and basically re-implements\n__hid_device_probe() by calling hid_parse() and hid_hw_start() but not\ndevres_open_group(). hid_device_probe() does not call __hid_device_probe()\nfor it. Later, when the driver is removed, hid_device_remove() calls\ndevres_release_group() as it doesn\u0026apos;t check whether hdev-\u0026gt;driver was\ninitially overridden or not.\n\nThe issue seems to be related to the commit 62c68e7cee33 (\u0026quot;HID: ensure\ntimely release of driver-allocated resources\u0026quot;) but the commit itself seems\nto be correct.\n\nFix the issue by dropping the \u0026apos;hid_dev-\u0026gt;driver\u0026apos; override and using\nhid_register_driver()/hid_unregister_driver() instead. Alternatively, it\nwould have been possible to rely on the default handling but\nHID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn\u0026apos;t seem to work\nfor mousevsc as-is.(CVE-2024-56545)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix usage slab after free\n\n[  +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[  +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147\n\n[  +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1\n[  +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020\n[  +0.000016] Call Trace:\n[  +0.000008]  \u0026lt;TASK\u0026gt;\n[  +0.000009]  dump_stack_lvl+0x76/0xa0\n[  +0.000017]  print_report+0xce/0x5f0\n[  +0.000017]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[  +0.000019]  ? srso_return_thunk+0x5/0x5f\n[  +0.000015]  ? kasan_complete_mode_report_info+0x72/0x200\n[  +0.000016]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[  +0.000019]  kasan_report+0xbe/0x110\n[  +0.000015]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[  +0.000023]  __asan_report_load8_noabort+0x14/0x30\n[  +0.000014]  drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[  +0.000020]  ? srso_return_thunk+0x5/0x5f\n[  +0.000013]  ? __kasan_check_write+0x14/0x30\n[  +0.000016]  ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched]\n[  +0.000020]  ? srso_return_thunk+0x5/0x5f\n[  +0.000013]  ? __kasan_check_write+0x14/0x30\n[  +0.000013]  ? srso_return_thunk+0x5/0x5f\n[  +0.000013]  ? enable_work+0x124/0x220\n[  +0.000015]  ? __pfx_enable_work+0x10/0x10\n[  +0.000013]  ? srso_return_thunk+0x5/0x5f\n[  +0.000014]  ? free_large_kmalloc+0x85/0xf0\n[  +0.000016]  drm_sched_entity_destroy+0x18/0x30 [gpu_sched]\n[  +0.000020]  amdgpu_vce_sw_fini+0x55/0x170 [amdgpu]\n[  +0.000735]  ? __kasan_check_read+0x11/0x20\n[  +0.000016]  vce_v4_0_sw_fini+0x80/0x110 [amdgpu]\n[  +0.000726]  amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu]\n[  +0.000679]  ? mutex_unlock+0x80/0xe0\n[  +0.000017]  ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu]\n[  +0.000662]  ? srso_return_thunk+0x5/0x5f\n[  +0.000014]  ? __kasan_check_write+0x14/0x30\n[  +0.000013]  ? srso_return_thunk+0x5/0x5f\n[  +0.000013]  ? mutex_unlock+0x80/0xe0\n[  +0.000016]  amdgpu_driver_release_kms+0x16/0x80 [amdgpu]\n[  +0.000663]  drm_minor_release+0xc9/0x140 [drm]\n[  +0.000081]  drm_release+0x1fd/0x390 [drm]\n[  +0.000082]  __fput+0x36c/0xad0\n[  +0.000018]  __fput_sync+0x3c/0x50\n[  +0.000014]  __x64_sys_close+0x7d/0xe0\n[  +0.000014]  x64_sys_call+0x1bc6/0x2680\n[  +0.000014]  do_syscall_64+0x70/0x130\n[  +0.000014]  ? srso_return_thunk+0x5/0x5f\n[  +0.000014]  ? irqentry_exit_to_user_mode+0x60/0x190\n[  +0.000015]  ? srso_return_thunk+0x5/0x5f\n[  +0.000014]  ? irqentry_exit+0x43/0x50\n[  +0.000012]  ? srso_return_thunk+0x5/0x5f\n[  +0.000013]  ? exc_page_fault+0x7c/0x110\n[  +0.000015]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  +0.000014] RIP: 0033:0x7ffff7b14f67\n[  +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff\n[  +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003\n[  +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67\n[  +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003\n[  +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000\n[  +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8\n[  +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040\n[  +0.000020]  \u0026lt;/TASK\u0026gt;\n\n[  +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:\n[  +0.000014]  kasan_save_stack+0x28/0x60\n[  +0.000008]  kasan_save_track+0x18/0x70\n[  +0.000007]  kasan_save_alloc_info+0x38/0x60\n[  +0.000007]  __kasan_kmalloc+0xc1/0xd0\n[  +0.000007]  kmalloc_trace_noprof+0x180/0x380\n[  +0.000007]  drm_sched_init+0x411/0xec0 [gpu_sched]\n[  +0.000012]  amdgpu_device_init+0x695f/0xa610 [amdgpu]\n[  +0.000658]  amdgpu_driver_load_kms+0x1a/0x120 [amdgpu]\n[  +0.000662]  amdgpu_pci_p\n---truncated---(CVE-2024-56551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: make sure exp active before svc_export_show\n\nThe function `e_show` was called with protection from RCU. This only\nensures that `exp` will not be freed. Therefore, the reference count for\n`exp` can drop to zero, which will trigger a refcount use-after-free\nwarning when `exp_get` is called. To resolve this issue, use\n`cache_get_rcu` to ensure that `exp` remains active.\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 3 PID: 819 at lib/refcount.c:25\nrefcount_warn_saturate+0xb1/0x120\nCPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb1/0x120\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n e_show+0x20b/0x230 [nfsd]\n seq_read_iter+0x589/0x770\n seq_read+0x1e5/0x270\n vfs_read+0x125/0x530\n ksys_read+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-56558)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: Avoid list corruption when removing a slab from the full list\n\nBoot with slub_debug=UFPZ.\n\nIf allocated object failed in alloc_consistency_checks, all objects of\nthe slab will be marked as used, and then the slab will be removed from\nthe partial list.\n\nWhen an object belonging to the slab got freed later, the remove_full()\nfunction is called. Because the slab is neither on the partial list nor\non the full list, it eventually lead to a list corruption (actually a\nlist poison being detected).\n\nSo we need to mark and isolate the slab page with metadata corruption,\ndo not put it back in circulation.\n\nBecause the debug caches avoid all the fastpaths, reusing the frozen bit\nto mark slab page with metadata corruption seems to be fine.\n\n[ 4277.385669] list_del corruption, ffffea00044b3e50-\u0026gt;next is LIST_POISON1 (dead000000000100)\n[ 4277.387023] ------------[ cut here ]------------\n[ 4277.387880] kernel BUG at lib/list_debug.c:56!\n[ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G           OE      6.6.1-1 #1\n[ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs]\n[ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91\n[ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082\n[ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000\n[ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff\n[ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0\n[ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910\n[ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0\n[ 4277.404049] FS:  0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000\n[ 4277.405357] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0\n[ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4277.410000] PKRU: 55555554\n[ 4277.410645] Call Trace:\n[ 4277.411234]  \u0026lt;TASK\u0026gt;\n[ 4277.411777]  ? die+0x32/0x80\n[ 4277.412439]  ? do_trap+0xd6/0x100\n[ 4277.413150]  ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.414158]  ? do_error_trap+0x6a/0x90\n[ 4277.414948]  ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.415915]  ? exc_invalid_op+0x4c/0x60\n[ 4277.416710]  ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.417675]  ? asm_exc_invalid_op+0x16/0x20\n[ 4277.418482]  ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.419466]  ? __list_del_entry_valid_or_report+0x7b/0xc0\n[ 4277.420410]  free_to_partial_list+0x515/0x5e0\n[ 4277.421242]  ? xfs_iext_remove+0x41a/0xa10 [xfs]\n[ 4277.422298]  xfs_iext_remove+0x41a/0xa10 [xfs]\n[ 4277.423316]  ? xfs_inodegc_worker+0xb4/0x1a0 [xfs]\n[ 4277.424383]  xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs]\n[ 4277.425490]  __xfs_bunmapi+0x50d/0x840 [xfs]\n[ 4277.426445]  xfs_itruncate_extents_flags+0x13a/0x490 [xfs]\n[ 4277.427553]  xfs_inactive_truncate+0xa3/0x120 [xfs]\n[ 4277.428567]  xfs_inactive+0x22d/0x290 [xfs]\n[ 4277.429500]  xfs_inodegc_worker+0xb4/0x1a0 [xfs]\n[ 4277.430479]  process_one_work+0x171/0x340\n[ 4277.431227]  worker_thread+0x277/0x390\n[ 4277.431962]  ? __pfx_worker_thread+0x10/0x10\n[ 4277.432752]  kthread+0xf0/0x120\n[ 4277.433382]  ? __pfx_kthread+0x10/0x10\n[ 4277.434134]  ret_from_fork+0x2d/0x50\n[ 4277.434837]  ? __pfx_kthread+0x10/0x10\n[ 4277.435566]  ret_from_fork_asm+0x1b/0x30\n[ 4277.436280]  \u0026lt;/TASK\u0026gt;(CVE-2024-56566)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefi/libstub: Free correct pointer on failure\n\ncmdline_ptr is an out parameter, which is not allocated by the function\nitself, and likely points into the caller\u0026apos;s stack.\n\ncmdline refers to the pool allocation that should be freed when cleaning\nup after a failure, so pass this instead to free_pool().(CVE-2024-56573)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ts2020: fix null-ptr-deref in ts2020_probe()\n\nKASAN reported a null-ptr-deref issue when executing the following\ncommand:\n\n  # echo ts2020 0x20 \u0026gt; /sys/bus/i2c/devices/i2c-0/new_device\n    KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n    CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24\n    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)\n    RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]\n    RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202\n    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809\n    RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010\n    RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6\n    R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790\n    R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001\n    FS:  00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0\n    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n    Call Trace:\n     \u0026lt;TASK\u0026gt;\n     ts2020_probe+0xad/0xe10 [ts2020]\n     i2c_device_probe+0x421/0xb40\n     really_probe+0x266/0x850\n    ...\n\nThe cause of the problem is that when using sysfs to dynamically register\nan i2c device, there is no platform data, but the probe process of ts2020\nneeds to use platform data, resulting in a null pointer being accessed.\n\nSolve this problem by adding checks to platform data.(CVE-2024-56574)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: i2c: tc358743: Fix crash in the probe error path when using polling\n\nIf an error occurs in the probe() function, we should remove the polling\ntimer that was alarmed earlier, otherwise the timer is called with\narguments that are already freed, which results in a crash.\n\n------------[ cut here ]------------\nWARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268\nModules linked in:\nCPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226\nHardware name: Diasom DS-RK3568-SOM-EVB (DT)\npstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __run_timers+0x244/0x268\nlr : __run_timers+0x1d4/0x268\nsp : ffffff80eff2baf0\nx29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00\nx26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00\nx23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000\nx20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff\nx17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e\nx14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000\nx11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009\nx8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480\nx5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240\nx2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0\nCall trace:\n __run_timers+0x244/0x268\n timer_expire_remote+0x50/0x68\n tmigr_handle_remote+0x388/0x39c\n run_timer_softirq+0x38/0x44\n handle_softirqs+0x138/0x298\n __do_softirq+0x14/0x20\n ____do_softirq+0x10/0x1c\n call_on_irq_stack+0x24/0x4c\n do_softirq_own_stack+0x1c/0x2c\n irq_exit_rcu+0x9c/0xcc\n el1_interrupt+0x48/0xc0\n el1h_64_irq_handler+0x18/0x24\n el1h_64_irq+0x7c/0x80\n default_idle_call+0x34/0x68\n do_idle+0x23c/0x294\n cpu_startup_entry+0x38/0x3c\n secondary_start_kernel+0x128/0x160\n __secondary_switched+0xb8/0xbc\n---[ end trace 0000000000000000 ]---(CVE-2024-56576)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mtk-jpeg: Fix null-ptr-deref during unload module\n\nThe workqueue should be destroyed in mtk_jpeg_core.c since commit\n09aea13ecf6f (\u0026quot;media: mtk-jpeg: refactor some variables\u0026quot;), otherwise\nthe below calltrace can be easily triggered.\n\n[  677.862514] Unable to handle kernel paging request at virtual address dfff800000000023\n[  677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\n...\n[  677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G           O       6.8.12-mtk+gfa1a78e5d24b+ #17\n...\n[  677.882838] pc : destroy_workqueue+0x3c/0x770\n[  677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]\n[  677.884314] sp : ffff80008ad974f0\n[  677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070\n[  677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690\n[  677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000\n[  677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0\n[  677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10\n[  677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d\n[  677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90\n[  677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001\n[  677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000\n[  677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118\n[  677.893977] Call trace:\n[  677.894297]  destroy_workqueue+0x3c/0x770\n[  677.894826]  mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]\n[  677.895677]  devm_action_release+0x50/0x90\n[  677.896211]  release_nodes+0xe8/0x170\n[  677.896688]  devres_release_all+0xf8/0x178\n[  677.897219]  device_unbind_cleanup+0x24/0x170\n[  677.897785]  device_release_driver_internal+0x35c/0x480\n[  677.898461]  device_release_driver+0x20/0x38\n...\n[  677.912665] ---[ end trace 0000000000000000 ]---(CVE-2024-56577)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: amphion: Set video drvdata before register video device\n\nThe video drvdata should be set before the video device is registered,\notherwise video_drvdata() may return NULL in the open() file ops, and led\nto oops.(CVE-2024-56579)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nleds: class: Protect brightness_show() with led_cdev-\u0026gt;led_access mutex\n\nThere is NULL pointer issue observed if from Process A where hid device\nbeing added which results in adding a led_cdev addition and later a\nanother call to access of led_cdev attribute from Process B can result\nin NULL pointer issue.\n\nUse mutex led_cdev-\u0026gt;led_access to protect access to led-\u0026gt;cdev and its\nattribute inside brightness_show() and max_brightness_show() and also\nupdate the comment for mutex that it should be used to protect the led\nclass device fields.\n\n\tProcess A \t\t\t\tProcess B\n\n kthread+0x114\n worker_thread+0x244\n process_scheduled_works+0x248\n uhid_device_add_worker+0x24\n hid_add_device+0x120\n device_add+0x268\n bus_probe_device+0x94\n device_initial_probe+0x14\n __device_attach+0xfc\n bus_for_each_drv+0x10c\n __device_attach_driver+0x14c\n driver_probe_device+0x3c\n __driver_probe_device+0xa0\n really_probe+0x190\n hid_device_probe+0x130\n ps_probe+0x990\n ps_led_register+0x94\n devm_led_classdev_register_ext+0x58\n led_classdev_register_ext+0x1f8\n device_create_with_groups+0x48\n device_create_groups_vargs+0xc8\n device_add+0x244\n kobject_uevent+0x14\n kobject_uevent_env[jt]+0x224\n mutex_unlock[jt]+0xc4\n __mutex_unlock_slowpath+0xd4\n wake_up_q+0x70\n try_to_wake_up[jt]+0x48c\n preempt_schedule_common+0x28\n __schedule+0x628\n __switch_to+0x174\n\t\t\t\t\t\tel0t_64_sync+0x1a8/0x1ac\n\t\t\t\t\t\tel0t_64_sync_handler+0x68/0xbc\n\t\t\t\t\t\tel0_svc+0x38/0x68\n\t\t\t\t\t\tdo_el0_svc+0x1c/0x28\n\t\t\t\t\t\tel0_svc_common+0x80/0xe0\n\t\t\t\t\t\tinvoke_syscall+0x58/0x114\n\t\t\t\t\t\t__arm64_sys_read+0x1c/0x2c\n\t\t\t\t\t\tksys_read+0x78/0xe8\n\t\t\t\t\t\tvfs_read+0x1e0/0x2c8\n\t\t\t\t\t\tkernfs_fop_read_iter+0x68/0x1b4\n\t\t\t\t\t\tseq_read_iter+0x158/0x4ec\n\t\t\t\t\t\tkernfs_seq_show+0x44/0x54\n\t\t\t\t\t\tsysfs_kf_seq_show+0xb4/0x130\n\t\t\t\t\t\tdev_attr_show+0x38/0x74\n\t\t\t\t\t\tbrightness_show+0x20/0x4c\n\t\t\t\t\t\tdualshock4_led_get_brightness+0xc/0x74\n\n[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060\n[ 3313.874301][ T4013] Mem abort info:\n[ 3313.874303][ T4013]   ESR = 0x0000000096000006\n[ 3313.874305][ T4013]   EC = 0x25: DABT (current EL), IL = 32 bits\n[ 3313.874307][ T4013]   SET = 0, FnV = 0\n[ 3313.874309][ T4013]   EA = 0, S1PTW = 0\n[ 3313.874311][ T4013]   FSC = 0x06: level 2 translation fault\n[ 3313.874313][ T4013] Data abort info:\n[ 3313.874314][ T4013]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 3313.874316][ T4013]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 3313.874318][ T4013]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000\n..\n\n[ 3313.874332][ T4013] Dumping ftrace buffer:\n[ 3313.874334][ T4013]    (ftrace buffer empty)\n..\n..\n[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader\n[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74\n[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60\n[ 3313.874656][ T4013] sp : ffffffc0b910bbd0\n..\n..\n[ 3313.874685][ T4013] Call trace:\n[ 3313.874687][ T4013]  dualshock4_led_get_brightness+0xc/0x74\n[ 3313.874690][ T4013]  brightness_show+0x20/0x4c\n[ 3313.874692][ T4013]  dev_attr_show+0x38/0x74\n[ 3313.874696][ T4013]  sysfs_kf_seq_show+0xb4/0x130\n[ 3313.874700][ T4013]  kernfs_seq_show+0x44/0x54\n[ 3313.874703][ T4013]  seq_read_iter+0x158/0x4ec\n[ 3313.874705][ T4013]  kernfs_fop_read_iter+0x68/0x1b4\n[ 3313.874708][ T4013]  vfs_read+0x1e0/0x2c8\n[ 3313.874711][ T4013]  ksys_read+0x78/0xe8\n[ 3313.874714][ T4013]  __arm64_sys_read+0x1c/0x2c\n[ 3313.874718][ T4013]  invoke_syscall+0x58/0x114\n[ 3313.874721][ T4013]  el0_svc_common+0x80/0xe0\n[ 3313.874724][ T4013]  do_el0_svc+0x1c/0x28\n[ 3313.874727][ T4013]  el0_svc+0x38/0x68\n[ 3313.874730][ T4013]  el0t_64_sync_handler+0x68/0xbc\n[ 3313.874732][ T4013]  el0t_64_sync+0x1a8/0x1ac(CVE-2024-56587)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()\n\nThis patch fixes a NULL pointer dereference bug in brcmfmac that occurs\nwhen a high \u0026apos;sd_sgentry_align\u0026apos; value applies (e.g. 512) and a lot of queued SKBs\nare sent from the pkt queue.\n\nThe problem is the number of entries in the pre-allocated sgtable, it is\nnents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) \u0026gt;\u0026gt; 4 + 1.\nGiven the default [rt]xglom_size=32 it\u0026apos;s actually 35 which is too small.\nWorst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB\nis added for each original SKB if tailroom isn\u0026apos;t enough to hold tail_pad.\nAt least one sg entry is needed for each SKB. So, eventually the \u0026quot;skb_queue_walk loop\u0026quot;\nin brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return\nNULL and this causes the oops.\n\nThe patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle\nthe worst-case.\nBtw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464\nadditional bytes of memory.(CVE-2024-56593)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: inet6: do not leave a dangling sk pointer in inet6_create()\n\nsock_init_data() attaches the allocated sk pointer to the provided sock\nobject. If inet6_create() fails later, the sk object is released, but the\nsock object retains the dangling sk pointer, which may cause use-after-free\nlater.\n\nClear the sock sk pointer on error.(CVE-2024-56600)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: inet: do not leave a dangling sk pointer in inet_create()\n\nsock_init_data() attaches the allocated sk object to the provided sock\nobject. If inet_create() fails later, the sk object is freed, but the\nsock object retains the dangling pointer, which may create use-after-free\nlater.\n\nClear the sk pointer in the sock object on error.(CVE-2024-56601)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ieee802154: do not leave a dangling sk pointer in ieee802154_create()\n\nsock_init_data() attaches the allocated sk object to the provided sock\nobject. If ieee802154_create() fails later, the allocated sk object is\nfreed, but the dangling pointer remains in the provided sock object, which\nmay allow use-after-free.\n\nClear the sk pointer in the sock object on error.(CVE-2024-56602)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_can: do not leave a dangling sk pointer in can_create()\n\nOn error can_create() frees the allocated sk object, but sock_init_data()\nhas already attached it to the provided sock object. This will leave a\ndangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: avoid erroring out after sock_init_data() in packet_create()\n\nAfter sock_init_data() the allocated sk object is attached to the provided\nsock object. On error, packet_create() frees the sk object leaving the\ndangling pointer in the sock object on return. Some other code may try\nto use this pointer and cause use-after-free.(CVE-2024-56606)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: dev: can_set_termination(): allow sleeping GPIOs\n\nIn commit 6e86a1543c37 (\u0026quot;can: dev: provide optional GPIO based\ntermination support\u0026quot;) GPIO based termination support was added.\n\nFor no particular reason that patch uses gpiod_set_value() to set the\nGPIO. This leads to the following warning, if the systems uses a\nsleeping GPIO, i.e. behind an I2C port expander:\n\n| WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c\n| CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c\n\nReplace gpiod_set_value() by gpiod_set_value_cansleep() to allow the\nuse of sleeping GPIOs.(CVE-2024-56625)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Add architecture specific huge_pte_clear()\n\nWhen executing mm selftests run_vmtests.sh, there is such an error:\n\n BUG: Bad page state in process uffd-unit-tests  pfn:00000\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0\n flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff)\n raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000\n raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat\n    virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse\n    nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs\n CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184\n Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022\n Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000\n         900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8\n         900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001\n         0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000\n         0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000\n         000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940\n         0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000\n         0000000000000000 90000000028f8940 ffff800000000000 0000000000000000\n         0000000000000000 0000000000000000 9000000000223a94 000000012001839c\n         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d\n         ...\n Call Trace:\n [\u0026lt;9000000000223a94\u0026gt;] show_stack+0x5c/0x180\n [\u0026lt;9000000001c3fd64\u0026gt;] dump_stack_lvl+0x6c/0xa0\n [\u0026lt;900000000056aa08\u0026gt;] bad_page+0x1a0/0x1f0\n [\u0026lt;9000000000574978\u0026gt;] free_unref_folios+0xbf0/0xd20\n [\u0026lt;90000000004e65cc\u0026gt;] folios_put_refs+0x1a4/0x2b8\n [\u0026lt;9000000000599a0c\u0026gt;] free_pages_and_swap_cache+0x164/0x260\n [\u0026lt;9000000000547698\u0026gt;] tlb_batch_pages_flush+0xa8/0x1c0\n [\u0026lt;9000000000547f30\u0026gt;] tlb_finish_mmu+0xa8/0x218\n [\u0026lt;9000000000543cb8\u0026gt;] exit_mmap+0x1a0/0x360\n [\u0026lt;9000000000247658\u0026gt;] __mmput+0x78/0x200\n [\u0026lt;900000000025583c\u0026gt;] do_exit+0x43c/0xde8\n [\u0026lt;9000000000256490\u0026gt;] do_group_exit+0x68/0x110\n [\u0026lt;9000000000256554\u0026gt;] sys_exit_group+0x1c/0x20\n [\u0026lt;9000000001c413b4\u0026gt;] do_syscall+0x94/0x130\n [\u0026lt;90000000002216d8\u0026gt;] handle_syscall+0xb8/0x158\n Disabling lock debugging due to kernel taint\n BUG: non-zero pgtables_bytes on freeing mm: -16384\n\nOn LoongArch system, invalid huge pte entry should be invalid_pte_table\nor a single _PAGE_HUGE bit rather than a zero value. And it should be\nthe same with invalid pmd entry, since pmd_none() is called by function\nfree_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single\n_PAGE_HUGE bit is also treated as a valid pte table and free_pte_range()\nwill be called in free_pmd_range().\n\n  free_pmd_range()\n        pmd = pmd_offset(pud, addr);\n        do {\n                next = pmd_addr_end(addr, end);\n                if (pmd_none_or_clear_bad(pmd))\n                        continue;\n                free_pte_range(tlb, pmd, addr);\n        } while (pmd++, addr = next, addr != end);\n\nHere invalid_pte_table is used for both invalid huge pte entry and\npmd entry.(CVE-2024-56628)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: do not assume mac header is set in geneve_xmit_skb()\n\nWe should not assume mac header is set in output path.\n\nUse skb_eth_hdr() instead of eth_hdr() to fix the issue.\n\nsysbot reported the following :\n\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline]\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline]\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline]\n WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039\nModules linked in:\nCPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline]\n RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline]\n RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline]\n RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039\nCode: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 \u0026lt;0f\u0026gt; 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff\nRSP: 0018:ffffc90003b2f870 EFLAGS: 00010283\nRAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000\nRDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003\nRBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff\nR10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000\nR13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23\nFS:  00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n  netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n  __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490\n  dev_direct_xmit include/linux/netdevice.h:3181 [inline]\n  packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285\n  packet_snd net/packet/af_packet.c:3146 [inline]\n  packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178\n  sock_sendmsg_nosec net/socket.c:711 [inline]\n  __sock_sendmsg net/socket.c:726 [inline]\n  __sys_sendto+0x488/0x4f0 net/socket.c:2197\n  __do_sys_sendto net/socket.c:2204 [inline]\n  __se_sys_sendto net/socket.c:2200 [inline]\n  __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56636)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ipset: Hold module reference while requesting a module\n\nUser space may unload ip_set.ko while it is itself requesting a set type\nbackend module, leading to a kernel crash. The race condition may be\nprovoked by inserting an mdelay() right after the nfnl_unlock() call.(CVE-2024-56637)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndccp: Fix memory leak in dccp_feat_change_recv\n\nIf dccp_feat_push_confirm() fails after new value for SP feature was accepted\nwithout reconciliation (\u0026apos;entry == NULL\u0026apos; branch), memory allocated for that value\nwith dccp_feat_clone_sp_val() is never freed.\n\nHere is the kmemleak stack for this:\n\nunreferenced object 0xffff88801d4ab488 (size 8):\n  comm \u0026quot;syz-executor310\u0026quot;, pid 1127, jiffies 4295085598 (age 41.666s)\n  hex dump (first 8 bytes):\n    01 b4 4a 1d 80 88 ff ff                          ..J.....\n  backtrace:\n    [\u0026lt;00000000db7cabfe\u0026gt;] kmemdup+0x23/0x50 mm/util.c:128\n    [\u0026lt;0000000019b38405\u0026gt;] kmemdup include/linux/string.h:465 [inline]\n    [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline]\n    [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline]\n    [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_change_recv net/dccp/feat.c:1145 [inline]\n    [\u0026lt;0000000019b38405\u0026gt;] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416\n    [\u0026lt;00000000b1f6d94a\u0026gt;] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125\n    [\u0026lt;0000000030d7b621\u0026gt;] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650\n    [\u0026lt;000000001f74c72e\u0026gt;] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688\n    [\u0026lt;00000000a6c24128\u0026gt;] sk_backlog_rcv include/net/sock.h:1041 [inline]\n    [\u0026lt;00000000a6c24128\u0026gt;] __release_sock+0x139/0x3b0 net/core/sock.c:2570\n    [\u0026lt;00000000cf1f3a53\u0026gt;] release_sock+0x54/0x1b0 net/core/sock.c:3111\n    [\u0026lt;000000008422fa23\u0026gt;] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline]\n    [\u0026lt;000000008422fa23\u0026gt;] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696\n    [\u0026lt;0000000015b6f64d\u0026gt;] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735\n    [\u0026lt;0000000010122488\u0026gt;] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865\n    [\u0026lt;00000000b4b70023\u0026gt;] __sys_connect+0x165/0x1a0 net/socket.c:1882\n    [\u0026lt;00000000f4cb3815\u0026gt;] __do_sys_connect net/socket.c:1892 [inline]\n    [\u0026lt;00000000f4cb3815\u0026gt;] __se_sys_connect net/socket.c:1889 [inline]\n    [\u0026lt;00000000f4cb3815\u0026gt;] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889\n    [\u0026lt;00000000e7b1e839\u0026gt;] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46\n    [\u0026lt;0000000055e91434\u0026gt;] entry_SYSCALL_64_after_hwframe+0x67/0xd1\n\nClean up the allocated memory in case of dccp_feat_push_confirm() failure\nand bail out with an error reset code.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-56643)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/ipv6: release expired exception dst cached in socket\n\nDst objects get leaked in ip6_negative_advice() when this function is\nexecuted for an expired IPv6 route located in the exception table. There\nare several conditions that must be fulfilled for the leak to occur:\n* an ICMPv6 packet indicating a change of the MTU for the path is received,\n  resulting in an exception dst being created\n* a TCP connection that uses the exception dst for routing packets must\n  start timing out so that TCP begins retransmissions\n* after the exception dst expires, the FIB6 garbage collector must not run\n  before TCP executes ip6_negative_advice() for the expired exception dst\n\nWhen TCP executes ip6_negative_advice() for an exception dst that has\nexpired and if no other socket holds a reference to the exception dst, the\nrefcount of the exception dst is 2, which corresponds to the increment\nmade by dst_init() and the increment made by the TCP socket for which the\nconnection is timing out. The refcount made by the socket is never\nreleased. The refcount of the dst is decremented in sk_dst_reset() but\nthat decrement is counteracted by a dst_hold() intentionally placed just\nbefore the sk_dst_reset() in ip6_negative_advice(). After\nip6_negative_advice() has finished, there is no other object tied to the\ndst. The socket lost its reference stored in sk_dst_cache and the dst is\nno longer in the exception table. The exception dst becomes a leaked\nobject.\n\nAs a result of this dst leak, an unbalanced refcount is reported for the\nloopback device of a net namespace being destroyed under kernels that do\nnot contain e5f80fcf869a (\u0026quot;ipv6: give an IPv6 dev to blackhole_netdev\u0026quot;):\nunregister_netdevice: waiting for lo to become free. Usage count = 2\n\nFix the dst leak by removing the dst_hold() in ip6_negative_advice(). The\npatch that introduced the dst_hold() in ip6_negative_advice() was\n92f1655aa2b22 (\u0026quot;net: fix __dst_negative_advice() race\u0026quot;). But 92f1655aa2b22\nmerely refactored the code with regards to the dst refcount so the issue\nwas present even before 92f1655aa2b22. The bug was introduced in\n54c1a859efd9f (\u0026quot;ipv6: Don\u0026apos;t drop cache route entry unless timer actually\nexpired.\u0026quot;) where the expired cached route is deleted and the sk_dst_cache\nmember of the socket is set to NULL by calling dst_negative_advice() but\nthe refcount belonging to the socket is left unbalanced.\n\nThe IPv4 version - ipv4_negative_advice() - is not affected by this bug.\nWhen the TCP connection times out ipv4_negative_advice() merely resets the\nsk_dst_cache of the socket while decrementing the refcount of the\nexception dst.(CVE-2024-56644)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: j1939_session_new(): fix skb reference counting\n\nSince j1939_session_skb_queue() does an extra skb_get() for each new\nskb, do the same for the initial one in j1939_session_new() to avoid\nrefcount underflow.\n\n[mkl: clean up commit message](CVE-2024-56645)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: fix LED ID check in led_tg_check()\n\nSyzbot has reported the following BUG detected by KASAN:\n\nBUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70\nRead of size 1 at addr ffff8881022da0c8 by task repro/5879\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x241/0x360\n ? __pfx_dump_stack_lvl+0x10/0x10\n ? __pfx__printk+0x10/0x10\n ? _printk+0xd5/0x120\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x183/0x530\n print_report+0x169/0x550\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x45f/0x530\n ? __phys_addr+0xba/0x170\n ? strlen+0x58/0x70\n kasan_report+0x143/0x180\n ? strlen+0x58/0x70\n strlen+0x58/0x70\n kstrdup+0x20/0x80\n led_tg_check+0x18b/0x3c0\n xt_check_target+0x3bb/0xa40\n ? __pfx_xt_check_target+0x10/0x10\n ? stack_depot_save_flags+0x6e4/0x830\n ? nft_target_init+0x174/0xc30\n nft_target_init+0x82d/0xc30\n ? __pfx_nft_target_init+0x10/0x10\n ? nf_tables_newrule+0x1609/0x2980\n ? nf_tables_newrule+0x1609/0x2980\n ? rcu_is_watching+0x15/0xb0\n ? nf_tables_newrule+0x1609/0x2980\n ? nf_tables_newrule+0x1609/0x2980\n ? __kmalloc_noprof+0x21a/0x400\n nf_tables_newrule+0x1860/0x2980\n ? __pfx_nf_tables_newrule+0x10/0x10\n ? __nla_parse+0x40/0x60\n nfnetlink_rcv+0x14e5/0x2ab0\n ? __pfx_validate_chain+0x10/0x10\n ? __pfx_nfnetlink_rcv+0x10/0x10\n ? __lock_acquire+0x1384/0x2050\n ? netlink_deliver_tap+0x2e/0x1b0\n ? __pfx_lock_release+0x10/0x10\n ? netlink_deliver_tap+0x2e/0x1b0\n netlink_unicast+0x7f8/0x990\n ? __pfx_netlink_unicast+0x10/0x10\n ? __virt_addr_valid+0x183/0x530\n ? __check_object_size+0x48e/0x900\n netlink_sendmsg+0x8e4/0xcb0\n ? __pfx_netlink_sendmsg+0x10/0x10\n ? aa_sock_msg_perm+0x91/0x160\n ? __pfx_netlink_sendmsg+0x10/0x10\n __sock_sendmsg+0x223/0x270\n ____sys_sendmsg+0x52a/0x7e0\n ? __pfx_____sys_sendmsg+0x10/0x10\n __sys_sendmsg+0x292/0x380\n ? __pfx___sys_sendmsg+0x10/0x10\n ? lockdep_hardirqs_on_prepare+0x43d/0x780\n ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10\n ? exc_page_fault+0x590/0x8c0\n ? do_syscall_64+0xb6/0x230\n do_syscall_64+0xf3/0x230\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...\n \u0026lt;/TASK\u0026gt;\n\nSince an invalid (without \u0026apos;\\0\u0026apos; byte at all) byte sequence may be passed\nfrom userspace, add an extra check to ensure that such a sequence is\nrejected as possible ID and so never passed to \u0026apos;kstrdup()\u0026apos; and further.(CVE-2024-56650)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: hi311x: hi3110_can_ist(): fix potential use-after-free\n\nThe commit a22bd630cfff (\u0026quot;can: hi311x: do not report txerr and rxerr\nduring bus-off\u0026quot;) removed the reporting of rxerr and txerr even in case\nof correct operation (i. e. not bus-off).\n\nThe error count information added to the CAN frame after netif_rx() is\na potential use after free, since there is no guarantee that the skb\nis in the same state. It might be freed or reused.\n\nFix the issue by postponing the netif_rx() call in case of txerr and\nrxerr reporting.(CVE-2024-56651)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm/fault: Fix kfence page fault reporting\n\ncopy_from_kernel_nofault() can be called when doing read of /proc/kcore.\n/proc/kcore can have some unmapped kfence objects which when read via\ncopy_from_kernel_nofault() can cause page faults. Since *_nofault()\nfunctions define their own fixup table for handling fault, use that\ninstead of asking kfence to handle such faults.\n\nHence we search the exception tables for the nip which generated the\nfault. If there is an entry then we let the fixup table handler handle the\npage fault by returning an error from within ___do_page_fault().\n\nThis can be easily triggered if someone tries to do dd from /proc/kcore.\neg. dd if=/proc/kcore of=/dev/null bs=1M\n\nSome example false negatives:\n\n  ===============================\n  BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0\n  Invalid read at 0xc0000000fdff0000:\n   copy_from_kernel_nofault+0x9c/0x1a0\n   0xc00000000665f950\n   read_kcore_iter+0x57c/0xa04\n   proc_reg_read_iter+0xe4/0x16c\n   vfs_read+0x320/0x3ec\n   ksys_read+0x90/0x154\n   system_call_exception+0x120/0x310\n   system_call_vectored_common+0x15c/0x2ec\n\n  BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0\n  Use-after-free read at 0xc0000000fe050000 (in kfence-#2):\n   copy_from_kernel_nofault+0x9c/0x1a0\n   0xc00000000665f950\n   read_kcore_iter+0x57c/0xa04\n   proc_reg_read_iter+0xe4/0x16c\n   vfs_read+0x320/0x3ec\n   ksys_read+0x90/0x154\n   system_call_exception+0x120/0x310\n   system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks \u0026apos;mmio\u0026apos;\n\nIf platform_get_resource_byname() fails and returns NULL because DT lacks\nan \u0026apos;mmio\u0026apos; property for the MHI endpoint, dereferencing res-\u0026gt;start will\ncause a NULL pointer access. Add a check to prevent it.\n\n[kwilczynski: error message update per the review feedback]\n[bhelgaas: commit log](CVE-2024-56689)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c\n\nAdd error pointer checks after calling otx2_mbox_get_rsp().(CVE-2024-56707)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices\n\nWhile design wise the idea of converting the driver to use\nthe hierarchy of the IRQ chips is correct, the implementation\nhas (inherited) flaws. This was unveiled when platform_get_irq()\nhad started WARN() on IRQ 0 that is supposed to be a Linux\nIRQ number (also known as vIRQ).\n\nRework the driver to respect IRQ domain when creating each MFD\ndevice separately, as the domain is not the same for all of them.(CVE-2024-56723)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device\n\nWhile design wise the idea of converting the driver to use\nthe hierarchy of the IRQ chips is correct, the implementation\nhas (inherited) flaws. This was unveiled when platform_get_irq()\nhad started WARN() on IRQ 0 that is supposed to be a Linux\nIRQ number (also known as vIRQ).\n\nRework the driver to respect IRQ domain when creating each MFD\ndevice separately, as the domain is not the same for all of them.(CVE-2024-56724)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c\n\nAdd error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c\n\nAdding error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()\n\nWhen information such as info-\u0026gt;screen_base is not ready, calling\nsh7760fb_free_mem() does not release memory correctly. Call\ndma_free_coherent() instead.(CVE-2024-56746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: release nexthop on device removal\n\nThe CI is hitting some aperiodic hangup at device removal time in the\npmtu.sh self-test:\n\nunregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6\nref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at\n\tdst_init+0x84/0x4a0\n\tdst_alloc+0x97/0x150\n\tip6_dst_alloc+0x23/0x90\n\tip6_rt_pcpu_alloc+0x1e6/0x520\n\tip6_pol_route+0x56f/0x840\n\tfib6_rule_lookup+0x334/0x630\n\tip6_route_output_flags+0x259/0x480\n\tip6_dst_lookup_tail.constprop.0+0x5c2/0x940\n\tip6_dst_lookup_flow+0x88/0x190\n\tudp_tunnel6_dst_lookup+0x2a7/0x4c0\n\tvxlan_xmit_one+0xbde/0x4a50 [vxlan]\n\tvxlan_xmit+0x9ad/0xf20 [vxlan]\n\tdev_hard_start_xmit+0x10e/0x360\n\t__dev_queue_xmit+0xf95/0x18c0\n\tarp_solicit+0x4a2/0xe00\n\tneigh_probe+0xaa/0xf0\n\nWhile the first suspect is the dst_cache, explicitly tracking the dst\nowing the last device reference via probes proved such dst is held by\nthe nexthop in the originating fib6_info.\n\nSimilar to commit f5b51fe804ec (\u0026quot;ipv6: route: purge exception on\nremoval\u0026quot;), we need to explicitly release the originating fib info when\ndisconnecting a to-be-removed device from a live ipv6 dst: move the\nfib6_info cleanup into ip6_dst_ifdown().\n\nTested running:\n\n./pmtu.sh cleanup_ipv6_exception\n\nin a tight loop for more than 400 iterations with no spat, running an\nunpatched kernel  I observed a splat every ~10 iterations.(CVE-2024-56751)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: caam - Fix the pointer passed to caam_qi_shutdown()\n\nThe type of the last parameter given to devm_add_action_or_reset() is\n\u0026quot;struct caam_drv_private *\u0026quot;, but in caam_qi_shutdown(), it is casted to\n\u0026quot;struct device *\u0026quot;.\n\nPass the correct parameter to devm_add_action_or_reset() so that the\nresources are released as expected.(CVE-2024-56754)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: add a sanity check for btrfs root in btrfs_search_slot()\n\nSyzbot reports a null-ptr-deref in btrfs_search_slot().\n\nThe reproducer is using rescue=ibadroots, and the extent tree root is\ncorrupted thus the extent tree is NULL.\n\nWhen scrub tries to search the extent tree to gather the needed extent\ninfo, btrfs_search_slot() doesn\u0026apos;t check if the target root is NULL or\nnot, resulting the null-ptr-deref.\n\nAdd sanity check for btrfs root before using it in btrfs_search_slot().(CVE-2024-56774)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_socket: remove WARN_ON_ONCE on maximum cgroup level\n\ncgroup maximum depth is INT_MAX by default, there is a cgroup toggle to\nrestrict this maximum depth to a more reasonable value not to harm\nperformance. Remove unnecessary WARN_ON_ONCE which is reachable from\nuserspace.(CVE-2024-56783)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a\n\nFix the dtc warnings:\n\n    arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: \u0026apos;#interrupt-cells\u0026apos; found, but node is not an interrupt provider\n    arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: \u0026apos;#interrupt-cells\u0026apos; found, but node is not an interrupt provider\n    arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite \u0026apos;interrupt_provider\u0026apos;\n\nAnd a runtime warning introduced in commit 045b14ca5c36 (\u0026quot;of: WARN on\ndeprecated #address-cells/#size-cells handling\u0026quot;):\n\n    WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0\n    Missing \u0026apos;#address-cells\u0026apos; in /bus@10000000/pci@1a000000/pci_bridge@9,0\n\nThe fix is similar to commit d89a415ff8d5 (\u0026quot;MIPS: Loongson64: DTS: Fix PCIe\nport nodes for ls7a\u0026quot;), which has fixed the issue for ls2k (despite its\nsubject mentions ls7a).(CVE-2024-56785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/entry: Mark IRQ entries to fix stack depot warnings\n\nThe stack depot filters out everything outside of the top interrupt\ncontext as an uninteresting or irrelevant part of the stack traces. This\nhelps with stack trace de-duplication, avoiding an explosion of saved\nstack traces that share the same IRQ context code path but originate\nfrom different randomly interrupted points, eventually exhausting the\nstack depot.\n\nFiltering uses in_irqentry_text() to identify functions within the\n.irqentry.text and .softirqentry.text sections, which then become the\nlast stack trace entries being saved.\n\nWhile __do_softirq() is placed into the .softirqentry.text section by\ncommon code, populating .irqentry.text is architecture-specific.\n\nCurrently, the .irqentry.text section on s390 is empty, which prevents\nstack depot filtering and de-duplication and could result in warnings\nlike:\n\nStack depot reached limit capacity\nWARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8\n\nwith PREEMPT and KASAN enabled.\n\nFix this by moving the IO/EXT interrupt handlers from .kprobes.text into\nthe .irqentry.text section and updating the kprobes blacklist to include\nthe .irqentry.text section.\n\nThis is done only for asynchronous interrupts and explicitly not for\nprogram checks, which are synchronous and where the context beyond the\nprogram check is important to preserve. Despite machine checks being\nsomewhat in between, they are extremely rare, and preserving context\nwhen possible is also of value.\n\nSVCs and Restart Interrupts are not relevant, one being always at the\nboundary to user space and the other being a one-time thing.\n\nIRQ entries filtering is also optionally used in ftrace function graph,\nwhere the same logic applies.(CVE-2024-57838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Fix resetting msg rx state after topology removal\n\nIf the MST topology is removed during the reception of an MST down reply\nor MST up request sideband message, the\ndrm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset\nfrom one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with\nthe reading/parsing of the message from another thread via\ndrm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is\npossible since the reader/parser doesn\u0026apos;t hold any lock while accessing\nthe reception state. This in turn can lead to a memory corruption in the\nreader/parser as described by commit bd2fccac61b4 (\u0026quot;drm/dp_mst: Fix MST\nsideband message body length check\u0026quot;).\n\nFix the above by resetting the message reception state if needed before\nreading/parsing a message. Another solution would be to hold the\ndrm_dp_mst_topology_mgr::lock for the whole duration of the message\nreception/parsing in drm_dp_mst_handle_down_rep() and\ndrm_dp_mst_handle_up_req(), however this would require a bigger change.\nSince the fix is also needed for stable, opting for the simpler solution\nin this patch.(CVE-2024-57876)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix mbss changed flags corruption on 32 bit systems\n\nOn 32-bit systems, the size of an unsigned long is 4 bytes,\nwhile a u64 is 8 bytes. Therefore, when using\nor_each_set_bit(bit, \u0026amp;bits, sizeof(changed) * BITS_PER_BYTE),\nthe code is incorrectly searching for a bit in a 32-bit\nvariable that is expected to be 64 bits in size,\nleading to incorrect bit finding.\n\nSolution: Ensure that the size of the bits variable is correctly\nadjusted for each architecture.\n\n Call Trace:\n  ? show_regs+0x54/0x58\n  ? __warn+0x6b/0xd4\n  ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]\n  ? report_bug+0x113/0x150\n  ? exc_overflow+0x30/0x30\n  ? handle_bug+0x27/0x44\n  ? exc_invalid_op+0x18/0x50\n  ? handle_exception+0xf6/0xf6\n  ? exc_overflow+0x30/0x30\n  ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]\n  ? exc_overflow+0x30/0x30\n  ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]\n  ? ieee80211_mesh_work+0xff/0x260 [mac80211]\n  ? cfg80211_wiphy_work+0x72/0x98 [cfg80211]\n  ? process_one_work+0xf1/0x1fc\n  ? worker_thread+0x2c0/0x3b4\n  ? kthread+0xc7/0xf0\n  ? mod_delayed_work_on+0x4c/0x4c\n  ? kthread_complete_and_exit+0x14/0x14\n  ? ret_from_fork+0x24/0x38\n  ? kthread_complete_and_exit+0x14/0x14\n  ? ret_from_fork_asm+0xf/0x14\n  ? entry_INT80_32+0xf0/0xf0\n\n[restore no-op path for no changes](CVE-2024-57899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Fix NULL pointer dereference on certain command aborts\n\nIf a command is queued to the final usable TRB of a ring segment, the\nenqueue pointer is advanced to the subsequent link TRB and no further.\nIf the command is later aborted, when the abort completion is handled\nthe dequeue pointer is advanced to the first TRB of the next segment.\n\nIf no further commands are queued, xhci_handle_stopped_cmd_ring() sees\nthe ring pointers unequal and assumes that there is a pending command,\nso it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.\n\nDon\u0026apos;t attempt timer setup if cur_cmd is NULL. The subsequent doorbell\nring likely is unnecessary too, but it\u0026apos;s harmless. Leave it alone.\n\nThis is probably Bug 219532, but no confirmation has been received.\n\nThe issue has been independently reproduced and confirmed fixed using\na USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.\nEverything continued working normally after several prevented crashes.(CVE-2024-57981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: handle a symlink read error correctly\n\nPatch series \u0026quot;Convert ocfs2 to use folios\u0026quot;.\n\nMark did a conversion of ocfs2 to use folios and sent it to me as a\ngiant patch for review ;-)\n\nSo I\u0026apos;ve redone it as individual patches, and credited Mark for the patches\nwhere his code is substantially the same.  It\u0026apos;s not a bad way to do it;\nhis patch had some bugs and my patches had some bugs.  Hopefully all our\nbugs were different from each other.  And hopefully Mark likes all the\nchanges I made to his code!\n\n\nThis patch (of 23):\n\nIf we can\u0026apos;t read the buffer, be sure to unlock the page before returning.(CVE-2024-58001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT\n\nIn PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible\ncontext. bpf_mem_alloc must be used in PREEMPT_RT. This patch is\nto enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT\nis enabled.\n\n[   35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n[   35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs\n[   35.118569] preempt_count: 1, expected: 0\n[   35.118571] RCU nest depth: 1, expected: 1\n[   35.118577] INFO: lockdep is turned off.\n    ...\n[   35.118647]  __might_resched+0x433/0x5b0\n[   35.118677]  rt_spin_lock+0xc3/0x290\n[   35.118700]  ___slab_alloc+0x72/0xc40\n[   35.118723]  __kmalloc_noprof+0x13f/0x4e0\n[   35.118732]  bpf_map_kzalloc+0xe5/0x220\n[   35.118740]  bpf_selem_alloc+0x1d2/0x7b0\n[   35.118755]  bpf_local_storage_update+0x2fa/0x8b0\n[   35.118784]  bpf_sk_storage_get_tracing+0x15a/0x1d0\n[   35.118791]  bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66\n[   35.118795]  bpf_trace_run3+0x222/0x400\n[   35.118820]  __bpf_trace_inet_sock_set_state+0x11/0x20\n[   35.118824]  trace_inet_sock_set_state+0x112/0x130\n[   35.118830]  inet_sk_state_store+0x41/0x90\n[   35.118836]  tcp_set_state+0x3b3/0x640\n\nThere is no need to adjust the gfp_flags passing to the\nbpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL.\nThe verifier has ensured GFP_KERNEL is passed only in sleepable context.\n\nIt has been an old issue since the first introduction of the\nbpf_local_storage ~5 years ago, so this patch targets the bpf-next.\n\nbpf_mem_alloc is needed to solve it, so the Fixes tag is set\nto the commit when bpf_mem_alloc was first used in the bpf_local_storage.(CVE-2024-58070)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: fix race between cancel_hw_scan and hw_scan completion\n\nThe rtwdev-\u0026gt;scanning flag isn\u0026apos;t protected by mutex originally, so\ncancel_hw_scan can pass the condition, but suddenly hw_scan completion\nunset the flag and calls ieee80211_scan_completed() that will free\nlocal-\u0026gt;hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and\nuse-after-free. Fix it by moving the check condition to where\nprotected by mutex.\n\n KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]\n CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G           OE\n Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019\n Workqueue: events cfg80211_conn_work [cfg80211]\n RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]\n Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d\n RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206\n RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001\n RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089\n RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000\n R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960\n R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000\n FS:  0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? show_regs+0x61/0x73\n  ? __die_body+0x20/0x73\n  ? die_addr+0x4f/0x7b\n  ? exc_general_protection+0x191/0x1db\n  ? asm_exc_general_protection+0x27/0x30\n  ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]\n  ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core]\n  ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core]\n  ? do_raw_spin_lock+0x75/0xdb\n  ? __pfx_do_raw_spin_lock+0x10/0x10\n  rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core]\n  ? _raw_spin_unlock+0xe/0x24\n  ? __mutex_lock.constprop.0+0x40c/0x471\n  ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core]\n  ? __mutex_lock_slowpath+0x13/0x1f\n  ? mutex_lock+0xa2/0xdc\n  ? __pfx_mutex_lock+0x10/0x10\n  rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core]\n  rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core]\n  ieee80211_scan_cancel+0x468/0x4d0 [mac80211]\n  ieee80211_prep_connection+0x858/0x899 [mac80211]\n  ieee80211_mgd_auth+0xbea/0xdde [mac80211]\n  ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211]\n  ? cfg80211_find_elem+0x15/0x29 [cfg80211]\n  ? is_bss+0x1b7/0x1d7 [cfg80211]\n  ieee80211_auth+0x18/0x27 [mac80211]\n  cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211]\n  cfg80211_conn_do_work+0x410/0xb81 [cfg80211]\n  ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211]\n  ? __kasan_check_read+0x11/0x1f\n  ? psi_group_change+0x8bc/0x944\n  ? __kasan_check_write+0x14/0x22\n  ? mutex_lock+0x8e/0xdc\n  ? __pfx_mutex_lock+0x10/0x10\n  ? __pfx___radix_tree_lookup+0x10/0x10\n  cfg80211_conn_work+0x245/0x34d [cfg80211]\n  ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211]\n  ? update_cfs_rq_load_avg+0x3bc/0x3d7\n  ? sched_clock_noinstr+0x9/0x1a\n  ? sched_clock+0x10/0x24\n  ? sched_clock_cpu+0x7e/0x42e\n  ? newidle_balance+0x796/0x937\n  ? __pfx_sched_clock_cpu+0x10/0x10\n  ? __pfx_newidle_balance+0x10/0x10\n  ? __kasan_check_read+0x11/0x1f\n  ? psi_group_change+0x8bc/0x944\n  ? _raw_spin_unlock+0xe/0x24\n  ? raw_spin_rq_unlock+0x47/0x54\n  ? raw_spin_rq_unlock_irq+0x9/0x1f\n  ? finish_task_switch.isra.0+0x347/0x586\n  ? __schedule+0x27bf/0x2892\n  ? mutex_unlock+0x80/0xd0\n  ? do_raw_spin_lock+0x75/0xdb\n  ? __pfx___schedule+0x10/0x10\n  process_scheduled_works+0x58c/0x821\n  worker_thread+0x4c7/0x586\n  ? __kasan_check_read+0x11/0x1f\n  kthread+0x285/0x294\n  ? __pfx_worker_thread+0x10/0x10\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x29/0x6f\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork_asm+0x1b/0x30\n  \u0026lt;/TASK\u0026gt;(CVE-2025-21729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error\n\nThis patch addresses a race condition for an ODP MR that can result in a\nCQE with an error on the UMR QP.\n\nDuring the __mlx5_ib_dereg_mr() flow, the following sequence of calls\noccurs:\n\nmlx5_revoke_mr()\n mlx5r_umr_revoke_mr()\n mlx5r_umr_post_send_wait()\n\nAt this point, the lkey is freed from the hardware\u0026apos;s perspective.\n\nHowever, concurrently, mlx5_ib_invalidate_range() might be triggered by\nanother task attempting to invalidate a range for the same freed lkey.\n\nThis task will:\n - Acquire the umem_odp-\u0026gt;umem_mutex lock.\n - Call mlx5r_umr_update_xlt() on the UMR QP.\n - Since the lkey has already been freed, this can lead to a CQE error,\n   causing the UMR QP to enter an error state [1].\n\nTo resolve this race condition, the umem_odp-\u0026gt;umem_mutex lock is now also\nacquired as part of the mlx5_revoke_mr() scope.  Upon successful revoke,\nwe set umem_odp-\u0026gt;private which points to that MR to NULL, preventing any\nfurther invalidation attempts on its lkey.\n\n[1] From dmesg:\n\n   infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error\n   cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n   cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n   cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n   cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2\n\n   WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]\n   Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core\n   CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626\n   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n   RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]\n   [..]\n   Call Trace:\n   \u0026lt;TASK\u0026gt;\n   mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib]\n   mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib]\n   __mmu_notifier_invalidate_range_start+0x1e1/0x240\n   zap_page_range_single+0xf1/0x1a0\n   madvise_vma_behavior+0x677/0x6e0\n   do_madvise+0x1a2/0x4b0\n   __x64_sys_madvise+0x25/0x30\n   do_syscall_64+0x6b/0x140\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21732)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix possible int overflows in nilfs_fiemap()\n\nSince nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result\nby being prepared to go through potentially maxblocks == INT_MAX blocks,\nthe value in n may experience an overflow caused by left shift of blkbits.\n\nWhile it is extremely unlikely to occur, play it safe and cast right hand\nexpression to wider type to mitigate the issue.\n\nFound by Linux Verification Center (linuxtesting.org) with static analysis\ntool SVACE.(CVE-2025-21736)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: ipheth: fix possible overflow in DPE length check\n\nOriginally, it was possible for the DPE length check to overflow if\nwDatagramIndex + wDatagramLength \u0026gt; U16_MAX. This could lead to an OoB\nread.\n\nMove the wDatagramIndex term to the other side of the inequality.\n\nAn existing condition ensures that wDatagramIndex \u0026lt; urb-\u0026gt;actual_length.(CVE-2025-21743)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context\n\nThe following bug report happened with a PREEMPT_RT kernel:\n\n  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog\n  preempt_count: 1, expected: 0\n  RCU nest depth: 0, expected: 0\n  get_random_u32+0x4f/0x110\n  clocksource_verify_choose_cpus+0xab/0x1a0\n  clocksource_verify_percpu.part.0+0x6b/0x330\n  clocksource_watchdog_kthread+0x193/0x1a0\n\nIt is due to the fact that clocksource_verify_choose_cpus() is invoked with\npreemption disabled.  This function invokes get_random_u32() to obtain\nrandom numbers for choosing CPUs.  The batched_entropy_32 local lock and/or\nthe base_crng.lock spinlock in driver/char/random.c will be acquired during\nthe call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot\nbe acquired in atomic context.\n\nFix this problem by using migrate_disable() to allow smp_processor_id() to\nbe reliably used without introducing atomic context. preempt_disable() is\nthen called after clocksource_verify_choose_cpus() but before the\nclocksource measurement is being run to avoid introducing unexpected\nlatency.(CVE-2025-21767)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: hub: Ignore non-compliant devices with too many configs or interfaces\n\nRobert Morris created a test program which can cause\nusb_hub_to_struct_hub() to dereference a NULL or inappropriate\npointer:\n\nOops: general protection fault, probably for non-canonical address\n0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI\nCPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14\nHardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x31/0x80\n ? exc_general_protection+0x1b4/0x3c0\n ? asm_exc_general_protection+0x26/0x30\n ? usb_hub_adjust_deviceremovable+0x78/0x110\n hub_probe+0x7c7/0xab0\n usb_probe_interface+0x14b/0x350\n really_probe+0xd0/0x2d0\n ? __pfx___device_attach_driver+0x10/0x10\n __driver_probe_device+0x6e/0x110\n driver_probe_device+0x1a/0x90\n __device_attach_driver+0x7e/0xc0\n bus_for_each_drv+0x7f/0xd0\n __device_attach+0xaa/0x1a0\n bus_probe_device+0x8b/0xa0\n device_add+0x62e/0x810\n usb_set_configuration+0x65d/0x990\n usb_generic_driver_probe+0x4b/0x70\n usb_probe_device+0x36/0xd0\n\nThe cause of this error is that the device has two interfaces, and the\nhub driver binds to interface 1 instead of interface 0, which is where\nusb_hub_to_struct_hub() looks.\n\nWe can prevent the problem from occurring by refusing to accept hub\ndevices that violate the USB spec by having more than one\nconfiguration or interface.(CVE-2025-21776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\norangefs: fix a oob in orangefs_debug_write\n\nI got a syzbot report: slab-out-of-bounds Read in\norangefs_debug_write... several people suggested fixes,\nI tested Al Viro\u0026apos;s suggestion and made this patch.(CVE-2025-21782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpiolib: Fix crash on error in gpiochip_get_ngpios()\n\nThe gpiochip_get_ngpios() uses chip_*() macros to print messages.\nHowever these macros rely on gpiodev to be initialised and set,\nwhich is not the case when called via bgpio_init(). In such a case\nthe printing messages will crash on NULL pointer dereference.\nReplace chip_*() macros by the respective dev_*() ones to avoid\nsuch crash.(CVE-2025-21783)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: csum: Fix OoB access in IP checksum code for negative lengths\n\nCommit 69e3a6aa6be2 (\u0026quot;LoongArch: Add checksum optimization for 64-bit\nsystem\u0026quot;) would cause an undefined shift and an out-of-bounds read.\n\nCommit 8bd795fedb84 (\u0026quot;arm64: csum: Fix OoB access in IP checksum code\nfor negative lengths\u0026quot;) fixes the same issue on ARM64.(CVE-2025-21789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: fix hang in nfsd4_shutdown_callback\n\nIf nfs4_client is in courtesy state then there is no point to send\nthe callback. This causes nfsd4_shutdown_callback to hang since\ncl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP\nnotifies NFSD that the connection was dropped.\n\nThis patch modifies nfsd4_run_cb_work to skip the RPC call if\nnfs4_client is in courtesy state.(CVE-2025-21795)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: clear acl_access/acl_default after releasing them\n\nIf getting acl_default fails, acl_access and acl_default will be released\nsimultaneously. However, acl_access will still retain a pointer pointing\nto the released posix_acl, which will trigger a WARNING in\nnfs3svc_release_getacl like this:\n\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 26 PID: 3199 at lib/refcount.c:28\nrefcount_warn_saturate+0xb5/0x170\nModules linked in:\nCPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted\n6.12.0-rc6-00079-g04ae226af01f-dirty #8\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb5/0x170\nCode: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75\ne4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff \u0026lt;0f\u0026gt; 0b eb\ncd 0f b6 1d 8a3\nRSP: 0018:ffffc90008637cd8 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380\nRBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56\nR10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001\nR13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0\nFS:  0000000000000000(0000) GS:ffff88871ed00000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? refcount_warn_saturate+0xb5/0x170\n ? __warn+0xa5/0x140\n ? refcount_warn_saturate+0xb5/0x170\n ? report_bug+0x1b1/0x1e0\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x17/0x40\n ? asm_exc_invalid_op+0x1a/0x20\n ? tick_nohz_tick_stopped+0x1e/0x40\n ? refcount_warn_saturate+0xb5/0x170\n ? refcount_warn_saturate+0xb5/0x170\n nfs3svc_release_getacl+0xc9/0xe0\n svc_process_common+0x5db/0xb60\n ? __pfx_svc_process_common+0x10/0x10\n ? __rcu_read_unlock+0x69/0xa0\n ? __pfx_nfsd_dispatch+0x10/0x10\n ? svc_xprt_received+0xa1/0x120\n ? xdr_init_decode+0x11d/0x190\n svc_process+0x2a7/0x330\n svc_handle_xprt+0x69d/0x940\n svc_recv+0x180/0x2d0\n nfsd+0x168/0x200\n ? __pfx_nfsd+0x10/0x10\n kthread+0x1a2/0x1e0\n ? kthread+0xf4/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nKernel panic - not syncing: kernel: panic_on_warn set ...\n\nClear acl_access/acl_default after posix_acl_release is called to prevent\nUAF from being triggered.(CVE-2025-21796)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nptp: Ensure info-\u0026gt;enable callback is always set\n\nThe ioctl and sysfs handlers unconditionally call the -\u0026gt;enable callback.\nNot all drivers implement that callback, leading to NULL dereferences.\nExample of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.\n\nInstead use a dummy callback if no better was specified by the driver.(CVE-2025-21814)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: mark GFP_NOIO around sysfs -\u0026gt;store()\n\nsysfs -\u0026gt;store is called with queue freezed, meantime we have several\n-\u0026gt;store() callbacks(update_nr_requests, wbt, scheduler) to allocate\nmemory with GFP_KERNEL which may run into direct reclaim code path,\nthen potential deadlock can be caused.\n\nFix the issue by marking NOIO around sysfs -\u0026gt;store()(CVE-2025-21817)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-82.0.0.86.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","kernel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","perf-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-82.0.0.86.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","kernel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","perf-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-82.0.0.86.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1286"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52926"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41935"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47143"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47809"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-48881"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53141"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53148"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53156"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53176"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53177"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53178"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53181"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53185"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53210"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53214"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53216"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53233"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-54456"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56531"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56533"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56539"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56545"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56551"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56558"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56566"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56573"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56574"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56576"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56577"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56579"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56587"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56593"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56600"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56601"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56602"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56603"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56606"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56625"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56628"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56636"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56637"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56643"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56644"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56645"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56650"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56651"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56678"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56689"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56704"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56707"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56723"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56724"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56725"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56727"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56746"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56751"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56754"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56774"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56783"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56785"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57838"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57876"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57899"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57981"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58001"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58070"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21729"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21732"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21736"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21743"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21767"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21776"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21782"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21783"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21789"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21795"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21796"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21814"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21817"}],"database_specific":{"severity":"High"}}