{"schema_version":"1.7.2","id":"OESA-2025-1032","modified":"2025-01-10T13:01:09Z","published":"2025-01-10T13:01:09Z","upstream":["CVE-2022-49034","CVE-2024-49906","CVE-2024-53114","CVE-2024-53126","CVE-2024-53127","CVE-2024-53134","CVE-2024-53136","CVE-2024-53146","CVE-2024-53147","CVE-2024-53151","CVE-2024-53154","CVE-2024-53161","CVE-2024-53163","CVE-2024-53165","CVE-2024-53170","CVE-2024-53173","CVE-2024-53186","CVE-2024-53197","CVE-2024-53202","CVE-2024-53217","CVE-2024-53221","CVE-2024-53227","CVE-2024-53230","CVE-2024-56538","CVE-2024-56548","CVE-2024-56569","CVE-2024-56575","CVE-2024-56578","CVE-2024-56581","CVE-2024-56584","CVE-2024-56598","CVE-2024-56604","CVE-2024-56608","CVE-2024-56615","CVE-2024-56620","CVE-2024-56624","CVE-2024-56627","CVE-2024-56629","CVE-2024-56630","CVE-2024-56665","CVE-2024-56675","CVE-2024-56681","CVE-2024-56683","CVE-2024-56692","CVE-2024-56693","CVE-2024-56700","CVE-2024-56702","CVE-2024-56708","CVE-2024-56709","CVE-2024-56741","CVE-2024-56744","CVE-2024-56748","CVE-2024-56752"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK  When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning similar as below when showing /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.  [    3.052463] ------------[ cut here ]------------ [    3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [    3.070072] Modules linked in: efivarfs autofs4 [    3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [    3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [    3.109127]         9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [    3.118774]         90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [    3.128412]         0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [    3.138056]         0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [    3.147711]         ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [    3.157364]         900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [    3.167012]         0000000000000009 000000000000006c 0000000000000000 0000000000000000 [    3.176641]         9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [    3.186260]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [    3.195868]         ... [    3.199917] Call Trace: [    3.203941] [\u0026lt;90000000002086d8\u0026gt;] show_stack+0x38/0x14c [    3.210666] [\u0026lt;9000000000cf846c\u0026gt;] dump_stack_lvl+0x60/0x88 [    3.217625] [\u0026lt;900000000023d268\u0026gt;] __warn+0xd0/0x100 [    3.223958] [\u0026lt;9000000000cf3c90\u0026gt;] warn_slowpath_fmt+0x7c/0xcc [    3.231150] [\u0026lt;9000000000210220\u0026gt;] show_cpuinfo+0x5e8/0x5f0 [    3.238080] [\u0026lt;90000000004f578c\u0026gt;] seq_read_iter+0x354/0x4b4 [    3.245098] [\u0026lt;90000000004c2e90\u0026gt;] new_sync_read+0x17c/0x1c4 [    3.252114] [\u0026lt;90000000004c5174\u0026gt;] vfs_read+0x138/0x1d0 [    3.258694] [\u0026lt;90000000004c55f8\u0026gt;] ksys_read+0x70/0x100 [    3.265265] [\u0026lt;9000000000cfde9c\u0026gt;] do_syscall+0x7c/0x94 [    3.271820] [\u0026lt;9000000000202fe4\u0026gt;] handle_syscall+0xc4/0x160 [    3.281824] ---[ end trace 8b484262b4b8c24c ]---(CVE-2022-49034)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointer before try to access it  [why \u0026amp; how] Change the order of the pipe_ctx-\u0026gt;plane_state check to ensure that plane_state is not null before accessing it.(CVE-2024-49906)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client  A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot.  These instructions aren\u0026apos;t intended to be advertised on Zen4 client so clear the capability.(CVE-2024-53114)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vdpa: solidrun: Fix UB bug with devres  In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string.  Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared.  Fix the bug by allocating the strings on the heap through devm_kasprintf().(CVE-2024-53126)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Revert \u0026quot;mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\u0026quot;  The commit 8396c793ffdf (\u0026quot;mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\u0026quot;) increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \u0026quot;swiotlb buffer is full\u0026quot; and data corruption on StarFive JH7110  At this stage no fix have been found, so it\u0026apos;s probably better to just revert the change.  This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.(CVE-2024-53127)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  pmdomain: imx93-blk-ctrl: correct remove path  The check condition should be \u0026apos;i \u0026lt; bc-\u0026gt;onecell_data.num_domains\u0026apos;, not \u0026apos;bc-\u0026gt;onecell_data.num_domains\u0026apos; which will make the look never finish and cause kernel panic.  Also disable runtime to address \u0026quot;imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\u0026quot;(CVE-2024-53134)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mm: revert \u0026quot;mm: shmem: fix data-race in shmem_getattr()\u0026quot;  Revert d949d1d14fa2 (\u0026quot;mm: shmem: fix data-race in shmem_getattr()\u0026quot;) as suggested by Chuck [1].  It is causing deadlocks when accessing tmpfs over NFS.  As Hugh commented, \u0026quot;added just to silence a syzbot sanitizer splat: added where there has never been any practical problem\u0026quot;.(CVE-2024-53136)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSD: Prevent a potential integer overflow  If the tag length is \u0026gt;= U32_MAX - 3 then the \u0026quot;length + 4\u0026quot; addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decode_cb_compound4res() does not have to perform arithmetic on the unsafe length value.(CVE-2024-53146)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  exfat: fix out-of-bounds access of directory entries  In the case of the directory size is greater than or equal to the cluster size, if start_clu becomes an EOF cluster(an invalid cluster) due to file system corruption, then the directory entry where ei-\u0026gt;hint_femp.eidx hint is outside the directory, resulting in an out-of-bounds access, which may cause further file system corruption.  This commit adds a check for start_clu, if it is an invalid cluster, the file or directory will be treated as empty.(CVE-2024-53147)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  svcrdma: Address an integer overflow  Dan Carpenter reports: \u0026gt; Commit 78147ca8b4a9 (\u0026quot;svcrdma: Add a \u0026quot;parsed chunk list\u0026quot; data \u0026gt; structure\u0026quot;) from Jun 22, 2020 (linux-next), leads to the following \u0026gt; Smatch static checker warning: \u0026gt; \u0026gt; net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk() \u0026gt; warn: potential user controlled sizeof overflow \u0026apos;segcount * 4 * 4\u0026apos; \u0026gt; \u0026gt; net/sunrpc/xprtrdma/svc_rdma_recvfrom.c \u0026gt;     488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt) \u0026gt;     489 { \u0026gt;     490         u32 segcount; \u0026gt;     491         __be32 *p; \u0026gt;     492 \u0026gt;     493         if (xdr_stream_decode_u32(\u0026amp;rctxt-\u0026gt;rc_stream, \u0026amp;segcount)) \u0026gt;                                                               ^^^^^^^^ \u0026gt; \u0026gt;     494                 return false; \u0026gt;     495 \u0026gt;     496         /* A bogus segcount causes this buffer overflow check to fail. */ \u0026gt;     497         p = xdr_inline_decode(\u0026amp;rctxt-\u0026gt;rc_stream, \u0026gt; --\u0026gt; 498                               segcount * rpcrdma_segment_maxsz * sizeof(*p)); \u0026gt; \u0026gt; \u0026gt; segcount is an untrusted u32.  On 32bit systems anything \u0026gt;= SIZE_MAX / 16 will \u0026gt; have an integer overflow and some those values will be accepted by \u0026gt; xdr_inline_decode().(CVE-2024-53151)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  clk: clk-apple-nco: Add NULL check in applnco_probe  Add NULL check in applnco_probe, to handle kernel NULL pointer dereference error.(CVE-2024-53154)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  EDAC/bluefield: Fix potential integer overflow  The 64-bit argument for the \u0026quot;get DIMM info\u0026quot; SMC call consists of mem_ctrl_idx left-shifted 16 bits and OR-ed with DIMM index.  With mem_ctrl_idx defined as 32-bits wide the left-shift operation truncates the upper 16 bits of information during the calculation of the SMC argument.  The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any potential integer overflow, i.e. loss of data from upper 16 bits.(CVE-2024-53161)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  crypto: qat/qat_420xx - fix off by one in uof_get_name()  This is called from uof_get_name_420xx() where \u0026quot;num_objs\u0026quot; is the ARRAY_SIZE() of fw_objs[].  The \u0026gt; needs to be \u0026gt;= to prevent an out of bounds access.(CVE-2024-53163)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  sh: intc: Fix use-after-free bug in register_intc_controller()  In the error handling for this function, d is freed without ever removing it from intc_list which would lead to a use after free. To fix this, let\u0026apos;s only add it to the list after everything has succeeded.(CVE-2024-53165)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  block: fix uaf for flush rq while iterating tags  blk_mq_clear_flush_rq_mapping() is not called during scsi probe, by checking blk_queue_init_done(). However, QUEUE_FLAG_INIT_DONE is cleared in del_gendisk by commit aec89dc5d421 (\u0026quot;block: keep q_usage_counter in atomic mode after del_gendisk\u0026quot;), hence for disk like scsi, following blk_mq_destroy_queue() will not clear flush rq from tags-\u0026gt;rqs[] as well, cause following uaf that is found by our syzkaller for v6.6:  ================================================================== BUG: KASAN: slab-use-after-free in blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261 Read of size 4 at addr ffff88811c969c20 by task kworker/1:2H/224909  CPU: 1 PID: 224909 Comm: kworker/1:2H Not tainted 6.6.0-ga836a5060850 #32 Workqueue: kblockd blk_mq_timeout_work Call Trace:  __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364 print_report+0x3e/0x70 mm/kasan/report.c:475 kasan_report+0xb8/0xf0 mm/kasan/report.c:588 blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261 bt_iter block/blk-mq-tag.c:288 [inline] __sbitmap_for_each_set include/linux/sbitmap.h:295 [inline] sbitmap_for_each_set include/linux/sbitmap.h:316 [inline] bt_for_each+0x455/0x790 block/blk-mq-tag.c:325 blk_mq_queue_tag_busy_iter+0x320/0x740 block/blk-mq-tag.c:534 blk_mq_timeout_work+0x1a3/0x7b0 block/blk-mq.c:1673 process_one_work+0x7c4/0x1450 kernel/workqueue.c:2631 process_scheduled_works kernel/workqueue.c:2704 [inline] worker_thread+0x804/0xe40 kernel/workqueue.c:2785 kthread+0x346/0x450 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:293  Allocated by task 942: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc mm/kasan/common.c:383 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:380 kasan_kmalloc include/linux/kasan.h:198 [inline] __do_kmalloc_node mm/slab_common.c:1007 [inline] __kmalloc_node+0x69/0x170 mm/slab_common.c:1014 kmalloc_node include/linux/slab.h:620 [inline] kzalloc_node include/linux/slab.h:732 [inline] blk_alloc_flush_queue+0x144/0x2f0 block/blk-flush.c:499 blk_mq_alloc_hctx+0x601/0x940 block/blk-mq.c:3788 blk_mq_alloc_and_init_hctx+0x27f/0x330 block/blk-mq.c:4261 blk_mq_realloc_hw_ctxs+0x488/0x5e0 block/blk-mq.c:4294 blk_mq_init_allocated_queue+0x188/0x860 block/blk-mq.c:4350 blk_mq_init_queue_data block/blk-mq.c:4166 [inline] blk_mq_init_queue+0x8d/0x100 block/blk-mq.c:4176 scsi_alloc_sdev+0x843/0xd50 drivers/scsi/scsi_scan.c:335 scsi_probe_and_add_lun+0x77c/0xde0 drivers/scsi/scsi_scan.c:1189 __scsi_scan_target+0x1fc/0x5a0 drivers/scsi/scsi_scan.c:1727 scsi_scan_channel drivers/scsi/scsi_scan.c:1815 [inline] scsi_scan_channel+0x14b/0x1e0 drivers/scsi/scsi_scan.c:1791 scsi_scan_host_selected+0x2fe/0x400 drivers/scsi/scsi_scan.c:1844 scsi_scan+0x3a0/0x3f0 drivers/scsi/scsi_sysfs.c:151 store_scan+0x2a/0x60 drivers/scsi/scsi_sysfs.c:191 dev_attr_store+0x5c/0x90 drivers/base/core.c:2388 sysfs_kf_write+0x11c/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x3fc/0x610 fs/kernfs/file.c:338 call_write_iter include/linux/fs.h:2083 [inline] new_sync_write+0x1b4/0x2d0 fs/read_write.c:493 vfs_write+0x76c/0xb00 fs/read_write.c:586 ksys_write+0x127/0x250 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2  Freed by task 244687: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 [inline] __kasan_slab_free+0x12a/0x1b0 mm/kasan/common.c:244 kasan_slab_free include/linux/kasan.h:164 [in ---truncated---(CVE-2024-53170)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSv4.0: Fix a use-after-free problem in the asynchronous open()  Yang Erkun reports that when two threads are opening files at the same time, and are forced to abort before a reply is seen, then the call to nfs_release_seqid() in nfs4_opendata_free() can result in a use-after-free of the pointer to the defunct rpc task of the other thread. The fix is to ensure that if the RPC call is aborted before the call to nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid() in nfs4_open_release() before the rpc_task is freed.(CVE-2024-53173)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix use-after-free in SMB request handling  A race condition exists between SMB request handling in `ksmbd_conn_handler_loop()` and the freeing of `ksmbd_conn` in the workqueue handler `handle_ksmbd_work()`. This leads to a UAF. - KASAN: slab-use-after-free Read in handle_ksmbd_work - KASAN: slab-use-after-free in rtlock_slowlock_locked  This race condition arises as follows: - `ksmbd_conn_handler_loop()` waits for `conn-\u0026gt;r_count` to reach zero:   `wait_event(conn-\u0026gt;r_count_q, atomic_read(\u0026amp;conn-\u0026gt;r_count) == 0);` - Meanwhile, `handle_ksmbd_work()` decrements `conn-\u0026gt;r_count` using   `atomic_dec_return(\u0026amp;conn-\u0026gt;r_count)`, and if it reaches zero, calls   `ksmbd_conn_free()`, which frees `conn`. - However, after `handle_ksmbd_work()` decrements `conn-\u0026gt;r_count`,   it may still access `conn-\u0026gt;r_count_q` in the following line:   `waitqueue_active(\u0026amp;conn-\u0026gt;r_count_q)` or `wake_up(\u0026amp;conn-\u0026gt;r_count_q)`   This results in a UAF, as `conn` has already been freed.  The discovery of this UAF can be referenced in the following PR for syzkaller\u0026apos;s support for SMB requests.(CVE-2024-53186)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices  A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usb_get_configuration for allocating dev-\u0026gt;config.  This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration.(CVE-2024-53197)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware_loader: Fix possible resource leak in fw_log_firmware_info()  The alg instance should be released under the exception path, otherwise there may be resource leak here.  To mitigate this, free the alg instance with crypto_free_shash when kmalloc fails.(CVE-2024-53202)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSD: Prevent NULL dereference in nfsd4_process_cb_update()  @ses is initialized to NULL. If __nfsd4_find_backchannel() finds no available backchannel session, setup_callback_client() will try to dereference @ses and segfault.(CVE-2024-53217)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix null-ptr-deref in f2fs_submit_page_bio()  There\u0026apos;s issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace:  \u0026lt;TASK\u0026gt;  f2fs_submit_page_bio+0x126/0x8b0 [f2fs]  __get_meta_page+0x1d4/0x920 [f2fs]  get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs]  validate_checkpoint+0xac/0x290 [f2fs]  f2fs_get_valid_checkpoint+0x207/0x950 [f2fs]  f2fs_fill_super+0x1007/0x39b0 [f2fs]  mount_bdev+0x183/0x250  legacy_get_tree+0xf4/0x1e0  vfs_get_tree+0x88/0x340  do_new_mount+0x283/0x5e0  path_mount+0x2b2/0x15b0  __x64_sys_mount+0x1fe/0x270  do_syscall_64+0x5f/0x170  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Above issue happens as the biset of the f2fs file system is not initialized before register \u0026quot;f2fs_fs_type\u0026quot;. To address above issue just register \u0026quot;f2fs_fs_type\u0026quot; at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized.(CVE-2024-53221)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: bfa: Fix use-after-free in bfad_im_module_exit()  BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20 Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303  Call Trace:  \u0026lt;TASK\u0026gt;  dump_stack_lvl+0x95/0xe0  print_report+0xcb/0x620  kasan_report+0xbd/0xf0  __lock_acquire+0x2aca/0x3a20  lock_acquire+0x19b/0x520  _raw_spin_lock+0x2b/0x40  attribute_container_unregister+0x30/0x160  fc_release_transport+0x19/0x90 [scsi_transport_fc]  bfad_im_module_exit+0x23/0x60 [bfa]  bfad_init+0xdb/0xff0 [bfa]  do_one_initcall+0xdc/0x550  do_init_module+0x22d/0x6b0  load_module+0x4e96/0x5ff0  init_module_from_file+0xcd/0x130  idempotent_init_module+0x330/0x620  __x64_sys_finit_module+0xb3/0x110  do_syscall_64+0xc1/0x1d0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  \u0026lt;/TASK\u0026gt;  Allocated by task 25303:  kasan_save_stack+0x24/0x50  kasan_save_track+0x14/0x30  __kasan_kmalloc+0x7f/0x90  fc_attach_transport+0x4f/0x4740 [scsi_transport_fc]  bfad_im_module_init+0x17/0x80 [bfa]  bfad_init+0x23/0xff0 [bfa]  do_one_initcall+0xdc/0x550  do_init_module+0x22d/0x6b0  load_module+0x4e96/0x5ff0  init_module_from_file+0xcd/0x130  idempotent_init_module+0x330/0x620  __x64_sys_finit_module+0xb3/0x110  do_syscall_64+0xc1/0x1d0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Freed by task 25303:  kasan_save_stack+0x24/0x50  kasan_save_track+0x14/0x30  kasan_save_free_info+0x3b/0x60  __kasan_slab_free+0x38/0x50  kfree+0x212/0x480  bfad_im_module_init+0x7e/0x80 [bfa]  bfad_init+0x23/0xff0 [bfa]  do_one_initcall+0xdc/0x550  do_init_module+0x22d/0x6b0  load_module+0x4e96/0x5ff0  init_module_from_file+0xcd/0x130  idempotent_init_module+0x330/0x620  __x64_sys_finit_module+0xb3/0x110  do_syscall_64+0xc1/0x1d0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Above issue happens as follows:  bfad_init   error = bfad_im_module_init()     fc_release_transport(bfad_im_scsi_transport_template);   if (error)     goto ext;  ext:   bfad_im_module_exit();     fc_release_transport(bfad_im_scsi_transport_template);     --\u0026gt; Trigger double release  Don\u0026apos;t call bfad_im_module_exit() if bfad_im_module_init() failed.(CVE-2024-53227)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()  cpufreq_cpu_get_raw() may return NULL if the cpu is not in policy-\u0026gt;cpus cpu mask and it will cause null pointer dereference, so check NULL for cppc_get_cpu_cost().(CVE-2024-53230)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm: zynqmp_kms: Unplug DRM device before removal  Prevent userspace accesses to the DRM device from causing use-after-frees by unplugging the device before we remove it. This causes any further userspace accesses to result in an error without further calls into this driver\u0026apos;s internals.(CVE-2024-56538)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  hfsplus: don\u0026apos;t query the device logical block size multiple times  Devices block sizes may change. One of these cases is a loop device by using ioctl LOOP_SET_BLOCK_SIZE.  While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the latter function reads a different io_size.  Using a new min_io_size initally set to sb_min_blocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not initialized.  Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096.  The produced KASAN report before the fix looks like this:  [  419.944641] ================================================================== [  419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a [  419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [  419.947612] [  419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [  419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [  419.950035] Call Trace: [  419.950384]  \u0026lt;TASK\u0026gt; [  419.950676]  dump_stack_lvl+0x57/0x78 [  419.951212]  ? hfsplus_read_wrapper+0x659/0xa0a [  419.951830]  print_report+0x14c/0x49e [  419.952361]  ? __virt_addr_valid+0x267/0x278 [  419.952979]  ? kmem_cache_debug_flags+0xc/0x1d [  419.953561]  ? hfsplus_read_wrapper+0x659/0xa0a [  419.954231]  kasan_report+0x89/0xb0 [  419.954748]  ? hfsplus_read_wrapper+0x659/0xa0a [  419.955367]  hfsplus_read_wrapper+0x659/0xa0a [  419.955948]  ? __pfx_hfsplus_read_wrapper+0x10/0x10 [  419.956618]  ? do_raw_spin_unlock+0x59/0x1a9 [  419.957214]  ? _raw_spin_unlock+0x1a/0x2e [  419.957772]  hfsplus_fill_super+0x348/0x1590 [  419.958355]  ? hlock_class+0x4c/0x109 [  419.958867]  ? __pfx_hfsplus_fill_super+0x10/0x10 [  419.959499]  ? __pfx_string+0x10/0x10 [  419.960006]  ? lock_acquire+0x3e2/0x454 [  419.960532]  ? bdev_name.constprop.0+0xce/0x243 [  419.961129]  ? __pfx_bdev_name.constprop.0+0x10/0x10 [  419.961799]  ? pointer+0x3f0/0x62f [  419.962277]  ? __pfx_pointer+0x10/0x10 [  419.962761]  ? vsnprintf+0x6c4/0xfba [  419.963178]  ? __pfx_vsnprintf+0x10/0x10 [  419.963621]  ? setup_bdev_super+0x376/0x3b3 [  419.964029]  ? snprintf+0x9d/0xd2 [  419.964344]  ? __pfx_snprintf+0x10/0x10 [  419.964675]  ? lock_acquired+0x45c/0x5e9 [  419.965016]  ? set_blocksize+0x139/0x1c1 [  419.965381]  ? sb_set_blocksize+0x6d/0xae [  419.965742]  ? __pfx_hfsplus_fill_super+0x10/0x10 [  419.966179]  mount_bdev+0x12f/0x1bf [  419.966512]  ? __pfx_mount_bdev+0x10/0x10 [  419.966886]  ? vfs_parse_fs_string+0xce/0x111 [  419.967293]  ? __pfx_vfs_parse_fs_string+0x10/0x10 [  419.967702]  ? __pfx_hfsplus_mount+0x10/0x10 [  419.968073]  legacy_get_tree+0x104/0x178 [  419.968414]  vfs_get_tree+0x86/0x296 [  419.968751]  path_mount+0xba3/0xd0b [  419.969157]  ? __pfx_path_mount+0x10/0x10 [  419.969594]  ? kmem_cache_free+0x1e2/0x260 [  419.970311]  do_mount+0x99/0xe0 [  419.970630]  ? __pfx_do_mount+0x10/0x10 [  419.971008]  __do_sys_mount+0x199/0x1c9 [  419.971397]  do_syscall_64+0xd0/0x135 [  419.971761]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [  419.972233] RIP: 0033:0x7c3cb812972e [  419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [  419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [  419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [  419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated---(CVE-2024-56548)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ftrace: Fix regression with module command in stack_trace_filter  When executing the following command:      # echo \u0026quot;write*:mod:ext3\u0026quot; \u0026gt; /sys/kernel/tracing/stack_trace_filter  The current mod command causes a null pointer dereference. While commit 0f17976568b3f (\u0026quot;ftrace: Fix regression with module command in stack_trace_filter\u0026quot;) has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash.(CVE-2024-56569)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: imx-jpeg: Ensure power suppliers be suspended before detach them  The power suppliers are always requested to suspend asynchronously, dev_pm_domain_detach() requires the caller to ensure proper synchronization of this function with power management callbacks. otherwise the detach may led to kernel panic, like below:  [ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040 [ 1457.116777] Mem abort info: [ 1457.119589]   ESR = 0x0000000096000004 [ 1457.123358]   EC = 0x25: DABT (current EL), IL = 32 bits [ 1457.128692]   SET = 0, FnV = 0 [ 1457.131764]   EA = 0, S1PTW = 0 [ 1457.134920]   FSC = 0x04: level 0 translation fault [ 1457.139812] Data abort info: [ 1457.142707]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1457.148196]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1457.153256]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000 [ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000 [ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec] [ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66 [ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT) [ 1457.199236] Workqueue: pm pm_runtime_work [ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290 [ 1457.214886] lr : __rpm_callback+0x48/0x1d8 [ 1457.218968] sp : ffff80008250bc50 [ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000 [ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240 [ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008 [ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff [ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674 [ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002 [ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0 [ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000 [ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000 [ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000 [ 1457.293510] Call trace: [ 1457.295946]  genpd_runtime_suspend+0x20/0x290 [ 1457.300296]  __rpm_callback+0x48/0x1d8 [ 1457.304038]  rpm_callback+0x6c/0x78 [ 1457.307515]  rpm_suspend+0x10c/0x570 [ 1457.311077]  pm_runtime_work+0xc4/0xc8 [ 1457.314813]  process_one_work+0x138/0x248 [ 1457.318816]  worker_thread+0x320/0x438 [ 1457.322552]  kthread+0x110/0x114 [ 1457.325767]  ret_from_fork+0x10/0x20(CVE-2024-56575)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: imx-jpeg: Set video drvdata before register video device  The video drvdata should be set before the video device is registered, otherwise video_drvdata() may return NULL in the open() file ops, and led to oops.(CVE-2024-56578)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: ref-verify: fix use-after-free after invalid ref action  At btrfs_ref_tree_mod() after we successfully inserted the new ref entry (local variable \u0026apos;ref\u0026apos;) into the respective block entry\u0026apos;s rbtree (local variable \u0026apos;be\u0026apos;), if we find an unexpected action of BTRFS_DROP_DELAYED_REF, we error out and free the ref entry without removing it from the block entry\u0026apos;s rbtree. Then in the error path of btrfs_ref_tree_mod() we call btrfs_free_ref_cache(), which iterates over all block entries and then calls free_block_entry() for each one, and there we will trigger a use-after-free when we are called against the block entry to which we added the freed ref entry to its rbtree, since the rbtree still points to the block entry, as we didn\u0026apos;t remove it from the rbtree before freeing it in the error path at btrfs_ref_tree_mod(). Fix this by removing the new ref entry from the rbtree before freeing it.  Syzbot report this with the following stack traces:     BTRFS error (device loop0 state EA):   Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615       __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523       update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512       btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594       btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754       btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116       btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314       btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline]       btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23       btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482       btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293       vfs_unlink+0x365/0x650 fs/namei.c:4469       do_unlinkat+0x4ae/0x830 fs/namei.c:4533       __do_sys_unlinkat fs/namei.c:4576 [inline]       __se_sys_unlinkat fs/namei.c:4569 [inline]       __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569       do_syscall_x64 arch/x86/entry/common.c:52 [inline]       do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83       entry_SYSCALL_64_after_hwframe+0x77/0x7f    BTRFS error (device loop0 state EA):   Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1       __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521       update_ref_for_cow+0x96a/0x11f0       btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594       btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754       btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116       btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411       __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030       btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline]       __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137       __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171       btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313       prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586       relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611       btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081       btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377       __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161       btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538    BTRFS error (device loop0 state EA):   Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615       __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523       update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512       btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594       btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754       btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116       btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411       __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030       btrfs_update_delayed_i ---truncated---(CVE-2024-56581)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  io_uring/tctx: work around xa_store() allocation error issue  syzbot triggered the following WARN_ON:  WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51  which is the  WARN_ON_ONCE(!xa_empty(\u0026amp;tctx-\u0026gt;xa));  sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with -\u0026gt;head being non-NULL even though no entries exist in the xarray.  Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found.(CVE-2024-56584)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: array-index-out-of-bounds fix in dtReadFirst  The value of stbl can be sometimes out of bounds due to a bad filesystem. Added a check with appopriate return of error code in that case.(CVE-2024-56598)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()  bt_sock_alloc() attaches allocated sk object to the provided sock object. If rfcomm_dlc_alloc() fails, we release the sk object, but leave the dangling pointer in the sock object, which may cause use-after-free.  Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().(CVE-2024-56604)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix out-of-bounds access in \u0026apos;dcn21_link_encoder_create\u0026apos;  An issue was identified in the dcn21_link_encoder_create function where an out-of-bounds access could occur when the hpd_source index was used to reference the link_enc_hpd_regs array. This array has a fixed size and the index was not being checked against the array\u0026apos;s bounds before accessing it.  This fix adds a conditional check to ensure that the hpd_source index is within the valid range of the link_enc_hpd_regs array. If the index is out of bounds, the function now returns NULL to prevent undefined behavior.  References:  [   65.920507] ------------[ cut here ]------------ [   65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29 [   65.920519] index 7 is out of range for type \u0026apos;dcn10_link_enc_hpd_registers [5]\u0026apos; [   65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G           OE      6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13 [   65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Weekly_20_04_2 04/29/2020 [   65.920527] Call Trace: [   65.920529]  \u0026lt;TASK\u0026gt; [   65.920532]  dump_stack_lvl+0x48/0x70 [   65.920541]  dump_stack+0x10/0x20 [   65.920543]  __ubsan_handle_out_of_bounds+0xa2/0xe0 [   65.920549]  dcn21_link_encoder_create+0xd9/0x140 [amdgpu] [   65.921009]  link_create+0x6d3/0xed0 [amdgpu] [   65.921355]  create_links+0x18a/0x4e0 [amdgpu] [   65.921679]  dc_create+0x360/0x720 [amdgpu] [   65.921999]  ? dmi_matches+0xa0/0x220 [   65.922004]  amdgpu_dm_init+0x2b6/0x2c90 [amdgpu] [   65.922342]  ? console_unlock+0x77/0x120 [   65.922348]  ? dev_printk_emit+0x86/0xb0 [   65.922354]  dm_hw_init+0x15/0x40 [amdgpu] [   65.922686]  amdgpu_device_init+0x26a8/0x33a0 [amdgpu] [   65.922921]  amdgpu_driver_load_kms+0x1b/0xa0 [amdgpu] [   65.923087]  amdgpu_pci_probe+0x1b7/0x630 [amdgpu] [   65.923087]  local_pci_probe+0x4b/0xb0 [   65.923087]  pci_device_probe+0xc8/0x280 [   65.923087]  really_probe+0x187/0x300 [   65.923087]  __driver_probe_device+0x85/0x130 [   65.923087]  driver_probe_device+0x24/0x110 [   65.923087]  __driver_attach+0xac/0x1d0 [   65.923087]  ? __pfx___driver_attach+0x10/0x10 [   65.923087]  bus_for_each_dev+0x7d/0xd0 [   65.923087]  driver_attach+0x1e/0x30 [   65.923087]  bus_add_driver+0xf2/0x200 [   65.923087]  driver_register+0x64/0x130 [   65.923087]  ? __pfx_amdgpu_init+0x10/0x10 [amdgpu] [   65.923087]  __pci_register_driver+0x61/0x70 [   65.923087]  amdgpu_init+0x7d/0xff0 [amdgpu] [   65.923087]  do_one_initcall+0x49/0x310 [   65.923087]  ? kmalloc_trace+0x136/0x360 [   65.923087]  do_init_module+0x6a/0x270 [   65.923087]  load_module+0x1fce/0x23a0 [   65.923087]  init_module_from_file+0x9c/0xe0 [   65.923087]  ? init_module_from_file+0x9c/0xe0 [   65.923087]  idempotent_init_module+0x179/0x230 [   65.923087]  __x64_sys_finit_module+0x5d/0xa0 [   65.923087]  do_syscall_64+0x76/0x120 [   65.923087]  entry_SYSCALL_64_after_hwframe+0x6e/0x76 [   65.923087] RIP: 0033:0x7f2d80f1e88d [   65.923087] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [   65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [   65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d [   65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f [   65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002 [   65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480 [   65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0 [   65.923087]  \u0026lt;/TASK\u0026gt; [   65.923927] ---[ end trace ]---(CVE-2024-56608)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: fix OOB devmap writes when deleting elements  Jordy reported issue against XSKMAP which also applies to DEVMAP - the index used for accessing map entry, due to being a signed integer, causes the OOB writes. Fix is simple as changing the type from int to u32, however, when compared to XSKMAP case, one more thing needs to be addressed.  When map is released from system via dev_map_free(), we iterate through all of the entries and an iterator variable is also an int, which implies OOB accesses. Again, change it to be u32.  Example splat below:  [  160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000 [  160.731662] #PF: supervisor read access in kernel mode [  160.736876] #PF: error_code(0x0000) - not-present page [  160.742095] PGD 0 P4D 0 [  160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [  160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487 [  160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [  160.767642] Workqueue: events_unbound bpf_map_free_deferred [  160.773308] RIP: 0010:dev_map_free+0x77/0x170 [  160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 \u0026lt;48\u0026gt; 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [  160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [  160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024 [  160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000 [  160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [  160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122 [  160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [  160.838310] FS:  0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [  160.846528] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [  160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [  160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [  160.874092] PKRU: 55555554 [  160.876847] Call Trace: [  160.879338]  \u0026lt;TASK\u0026gt; [  160.881477]  ? __die+0x20/0x60 [  160.884586]  ? page_fault_oops+0x15a/0x450 [  160.888746]  ? search_extable+0x22/0x30 [  160.892647]  ? search_bpf_extables+0x5f/0x80 [  160.896988]  ? exc_page_fault+0xa9/0x140 [  160.900973]  ? asm_exc_page_fault+0x22/0x30 [  160.905232]  ? dev_map_free+0x77/0x170 [  160.909043]  ? dev_map_free+0x58/0x170 [  160.912857]  bpf_map_free_deferred+0x51/0x90 [  160.917196]  process_one_work+0x142/0x370 [  160.921272]  worker_thread+0x29e/0x3b0 [  160.925082]  ? rescuer_thread+0x4b0/0x4b0 [  160.929157]  kthread+0xd4/0x110 [  160.932355]  ? kthread_park+0x80/0x80 [  160.936079]  ret_from_fork+0x2d/0x50 [  160.943396]  ? kthread_park+0x80/0x80 [  160.950803]  ret_from_fork_asm+0x11/0x20 [  160.958482]  \u0026lt;/TASK\u0026gt;(CVE-2024-56615)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: ufs: qcom: Only free platform MSIs when ESI is enabled  Otherwise, it will result in a NULL pointer dereference as below:  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace:  mutex_lock+0xc/0x54  platform_device_msi_free_irqs_all+0x14/0x20  ufs_qcom_remove+0x34/0x48 [ufs_qcom]  platform_remove+0x28/0x44  device_remove+0x4c/0x80  device_release_driver_internal+0xd8/0x178  driver_detach+0x50/0x9c  bus_remove_driver+0x6c/0xbc  driver_unregister+0x30/0x60  platform_driver_unregister+0x14/0x20  ufs_qcom_pltform_exit+0x18/0xb94 [ufs_qcom]  __arm64_sys_delete_module+0x180/0x260  invoke_syscall+0x44/0x100  el0_svc_common.constprop.0+0xc0/0xe0  do_el0_svc+0x1c/0x28  el0_svc+0x34/0xdc  el0t_64_sync_handler+0xc0/0xc4  el0t_64_sync+0x190/0x194(CVE-2024-56620)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iommufd: Fix out_fput in iommufd_fault_alloc()  As fput() calls the file-\u0026gt;f_op-\u0026gt;release op, where fault obj and ictx are getting released, there is no need to release these two after fput() one more time, which would result in imbalanced refcounts:   refcount_t: decrement hit 0; leaking memory.   WARNING: CPU: 48 PID: 2369 at lib/refcount.c:31 refcount_warn_saturate+0x60/0x230   Call trace:    refcount_warn_saturate+0x60/0x230 (P)    refcount_warn_saturate+0x60/0x230 (L)    iommufd_fault_fops_release+0x9c/0xe0 [iommufd]   ...   VFS: Close: file count is 0 (f_op=iommufd_fops [iommufd])   WARNING: CPU: 48 PID: 2369 at fs/open.c:1507 filp_flush+0x3c/0xf0   Call trace:    filp_flush+0x3c/0xf0 (P)    filp_flush+0x3c/0xf0 (L)    __arm64_sys_close+0x34/0x98   ...   imbalanced put on file reference count   WARNING: CPU: 48 PID: 2369 at fs/file.c:74 __file_ref_put+0x100/0x138   Call trace:    __file_ref_put+0x100/0x138 (P)    __file_ref_put+0x100/0x138 (L)    __fput_sync+0x4c/0xd0  Drop those two lines to fix the warnings above.(CVE-2024-56624)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read  An offset from client could be a negative value, It could lead to an out-of-bounds read from the stream_buf. Note that this issue is coming when setting \u0026apos;vfs objects = streams_xattr parameter\u0026apos; in ksmbd.conf.(CVE-2024-56627)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  HID: wacom: fix when get product name maybe null pointer  Due to incorrect dev-\u0026gt;product reporting by certain devices, null pointer dereferences occur when dev-\u0026gt;product is empty, leading to potential system crashes.  This issue was found on EXCELSIOR DL37-D05 device with Loongson-LS3A6000-7A2000-DL37 motherboard.  Kernel logs: [   56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci [   56.671638] usb 4-3: string descriptor 0 read error: -22 [   56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07 [   56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [   56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0 [   56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80 [   56.697732] Oops[#1]: [   56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G           OE      6.6.0-loong64-desktop #25.00.2000.015 [   56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024 [   56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0 [   56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000 [   56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000 [   56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005 [   56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000 [   56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028 [   56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000 [   56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000 [   56.697753]    ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom] [   56.697802]   ERA: 90000000066e35c8 strstr+0x28/0x120 [   56.697806]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [   56.697816]  PRMD: 0000000c (PPLV0 +PIE +PWE) [   56.697821]  EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [   56.697827]  ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) [   56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [   56.697835]  BADV: 0000000000000000 [   56.697836]  PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [   56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit [   56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3) [   56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000 [   56.697896]         0000000000000000 00000011fffffffd 0000000000000000 0000000000000000 [   56.697901]         0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0 [   56.697906]         90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c [   56.697911]         90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440 [   56.697916]         ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0 [   56.697921]         0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c [   56.697926]         ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000 [   56.697931]         90000001000bb8d0  ---truncated---(CVE-2024-56629)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: free inode when ocfs2_get_init_inode() fails  syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826 (\u0026quot;ocfs2: Handle error from dquot_initialize()\u0026quot;) forgot to call iput() when new_inode() succeeded and dquot_initialize() failed.(CVE-2024-56630)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog  Syzbot reported [1] crash that happens for following tracing scenario:    - create tracepoint perf event with attr.inherit=1, attach it to the     process and set bpf program to it   - attached process forks -\u0026gt; chid creates inherited event      the new child event shares the parent\u0026apos;s bpf program and tp_event     (hence prog_array) which is global for tracepoint    - exit both process and its child -\u0026gt; release both events   - first perf_event_detach_bpf_prog call will release tp_event-\u0026gt;prog_array     and second perf_event_detach_bpf_prog will crash, because     tp_event-\u0026gt;prog_array is NULL  The fix makes sure the perf_event_detach_bpf_prog checks prog_array is valid before it tries to remove the bpf program from it.  [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad(CVE-2024-56665)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors  Uprobes always use bpf_prog_run_array_uprobe() under tasks-trace-RCU protection. But it is possible to attach a non-sleepable BPF program to a uprobe, and non-sleepable BPF programs are freed via normal RCU (see __bpf_prog_put_noref()). This leads to UAF of the bpf_prog because a normal RCU grace period does not imply a tasks-trace-RCU grace period.  Fix it by explicitly waiting for a tasks-trace-RCU grace period after removing the attachment of a bpf_prog to a perf_event.(CVE-2024-56675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  crypto: bcm - add error check in the ahash_hmac_init function  The ahash_init functions may return fails. The ahash_hmac_init should not return ok when ahash_init returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error.(CVE-2024-56681)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/vc4: hdmi: Avoid hang with debug registers when suspended  Trying to read /sys/kernel/debug/dri/1/hdmi1_regs when the hdmi is disconnected results in a fatal system hang.  This is due to the pm suspend code disabling the dvp clock. That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG, which results in accesses hanging AXI bus.  Protect against this.(CVE-2024-56683)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on node blkaddr in truncate_node()  syzbot reports a f2fs bug as below:  ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Call Trace:  truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909  f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288  f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856  evict+0x4e8/0x9b0 fs/inode.c:723  f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986  f2fs_create+0x357/0x530 fs/f2fs/namei.c:394  lookup_open fs/namei.c:3595 [inline]  open_last_lookups fs/namei.c:3694 [inline]  path_openat+0x1c03/0x3590 fs/namei.c:3930  do_filp_open+0x235/0x490 fs/namei.c:3960  do_sys_openat2+0x13e/0x1d0 fs/open.c:1415  do_sys_open fs/open.c:1430 [inline]  __do_sys_openat fs/open.c:1446 [inline]  __se_sys_openat fs/open.c:1441 [inline]  __x64_sys_openat+0x247/0x2a0 fs/open.c:1441  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534  The root cause is: on a fuzzed image, blkaddr in nat entry may be corrupted, then it will cause system panic when using it in f2fs_invalidate_blocks(), to avoid this, let\u0026apos;s add sanity check on nat blkaddr in truncate_node().(CVE-2024-56692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  brd: defer automatic disk creation until module initialization succeeds  My colleague Wupeng found the following problems during fault injection:  BUG: unable to handle page fault for address: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__asan_load8+0x4c/0xa0 ... Call Trace:  \u0026lt;TASK\u0026gt;  blkdev_put_whole+0x41/0x70  bdev_release+0x1a3/0x250  blkdev_release+0x11/0x20  __fput+0x1d7/0x4a0  task_work_run+0xfc/0x180  syscall_exit_to_user_mode+0x1de/0x1f0  do_syscall_64+0x6b/0x170  entry_SYSCALL_64_after_hwframe+0x76/0x7e  loop_init() is calling loop_add() after __register_blkdev() succeeds and is ignoring disk_add() failure from loop_add(), for loop_add() failure is not fatal and successfully created disks are already visible to bdev_open().  brd_init() is currently calling brd_alloc() before __register_blkdev() succeeds and is releasing successfully created disks when brd_init() returns an error. This can cause UAF for the latter two case:  case 1:     T1: modprobe brd   brd_init     brd_alloc(0) // success       add_disk         disk_scan_partitions           bdev_file_open_by_dev // alloc file           fput // won\u0026apos;t free until back to userspace     brd_alloc(1) // failed since mem alloc error inject   // error path for modprobe will release code segment   // back to userspace   __fput     blkdev_release       bdev_release         blkdev_put_whole           bdev-\u0026gt;bd_disk-\u0026gt;fops-\u0026gt;release // fops is freed now, UAF!  case 2:     T1:                            T2: modprobe brd   brd_init     brd_alloc(0) // success                                    open(/dev/ram0)     brd_alloc(1) // fail   // error path for modprobe                                     close(/dev/ram0)                                    ...                                    /* UAF! */                                    bdev-\u0026gt;bd_disk-\u0026gt;fops-\u0026gt;release  Fix this problem by following what loop_init() does. Besides, reintroduce brd_devices_mutex to help serialize modifications to brd_list.(CVE-2024-56693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: wl128x: Fix atomicity violation in fmc_send_cmd()  Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev-\u0026gt;resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev-\u0026gt;resp_skb variable is assigned a null value. This results in an invalid fmdev-\u0026gt;resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev-\u0026gt;resp_skb; when the invalid fmdev-\u0026gt;resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb-\u0026gt;data;  To address this issue, it is recommended to include the validity check of fmdev-\u0026gt;resp_skb within the locked section of the function. This modification ensures that the value of fmdev-\u0026gt;resp_skb does not change during the validation process, thereby maintaining its validity.  This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations.(CVE-2024-56700)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Mark raw_tp arguments with PTR_MAYBE_NULL  Arguments to a raw tracepoint are tagged as trusted, which carries the semantics that the pointer will be non-NULL.  However, in certain cases, a raw tracepoint argument may end up being NULL. More context about this issue is available in [0].  Thus, there is a discrepancy between the reality, that raw_tp arguments can actually be NULL, and the verifier\u0026apos;s knowledge, that they are never NULL, causing explicit NULL checks to be deleted, and accesses to such pointers potentially crashing the kernel.  To fix this, mark raw_tp arguments as PTR_MAYBE_NULL, and then special case the dereference and pointer arithmetic to permit it, and allow passing them into helpers/kfuncs; these exceptions are made for raw_tp programs only. Ensure that we don\u0026apos;t do this when ref_obj_id \u0026gt; 0, as in that case this is an acquired object and doesn\u0026apos;t need such adjustment.  The reason we do mask_raw_tp_trusted_reg logic is because other will recheck in places whether the register is a trusted_reg, and then consider our register as untrusted when detecting the presence of the PTR_MAYBE_NULL flag.  To allow safe dereference, we enable PROBE_MEM marking when we see loads into trusted pointers with PTR_MAYBE_NULL.  While trusted raw_tp arguments can also be passed into helpers or kfuncs where such broken assumption may cause issues, a future patch set will tackle their case separately, as PTR_TO_BTF_ID (without PTR_TRUSTED) can already be passed into helpers and causes similar problems. Thus, they are left alone for now.  It is possible that these checks also permit passing non-raw_tp args that are trusted PTR_TO_BTF_ID with null marking. In such a case, allowing dereference when pointer is NULL expands allowed behavior, so won\u0026apos;t regress existing programs, and the case of passing these into helpers is the same as above and will be dealt with later.  Also update the failure case in tp_btf_nullable selftest to capture the new behavior, as the verifier will no longer cause an error when directly dereference a raw tracepoint argument marked as __nullable.    [0]: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb(CVE-2024-56702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  EDAC/igen6: Avoid segmentation fault on module unload  The segmentation fault happens because:  During modprobe: 1. In igen6_probe(), igen6_pvt will be allocated with kzalloc() 2. In igen6_register_mci(), mci-\u0026gt;pvt_info will point to    \u0026amp;igen6_pvt-\u0026gt;imc[mc]  During rmmod: 1. In mci_release() in edac_mc.c, it will kfree(mci-\u0026gt;pvt_info) 2. In igen6_remove(), it will kfree(igen6_pvt);  Fix this issue by setting mci-\u0026gt;pvt_info to NULL to avoid the double kfree.(CVE-2024-56708)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  io_uring: check if iowq is killed before queuing  task work can be executed after the task has gone through io_uring termination, whether it\u0026apos;s the final task_work run or the fallback path. In this case, task work will find -\u0026gt;io_wq being already killed and null\u0026apos;ed, which is a problem if it then tries to forward the request to io_queue_iowq(). Make io_queue_iowq() fail requests in this case.  Note that it also checks PF_KTHREAD, because the user can first close a DEFER_TASKRUN ring and shortly after kill the task, in which case -\u0026gt;iowq check would race.(CVE-2024-56709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  apparmor: test: Fix memory leak for aa_unpack_strdup()  The string allocated by kmemdup() in aa_unpack_strdup() is not freed and cause following memory leaks, free them to fix it.   unreferenced object 0xffffff80c6af8a50 (size 8):    comm \u0026quot;kunit_try_catch\u0026quot;, pid 225, jiffies 4294894407    hex dump (first 8 bytes):      74 65 73 74 69 6e 67 00                          testing.    backtrace (crc 5eab668b):      [\u0026lt;0000000001e3714d\u0026gt;] kmemleak_alloc+0x34/0x40      [\u0026lt;000000006e6c7776\u0026gt;] __kmalloc_node_track_caller_noprof+0x300/0x3e0      [\u0026lt;000000006870467c\u0026gt;] kmemdup_noprof+0x34/0x60      [\u0026lt;000000001176bb03\u0026gt;] aa_unpack_strdup+0xd0/0x18c      [\u0026lt;000000008ecde918\u0026gt;] policy_unpack_test_unpack_strdup_with_null_name+0xf8/0x3ec      [\u0026lt;0000000032ef8f77\u0026gt;] kunit_try_run_case+0x13c/0x3ac      [\u0026lt;00000000f3edea23\u0026gt;] kunit_generic_run_threadfn_adapter+0x80/0xec      [\u0026lt;00000000adf936cf\u0026gt;] kthread+0x2e8/0x374      [\u0026lt;0000000041bb1628\u0026gt;] ret_from_fork+0x10/0x20  unreferenced object 0xffffff80c2a29090 (size 8):    comm \u0026quot;kunit_try_catch\u0026quot;, pid 227, jiffies 4294894409    hex dump (first 8 bytes):      74 65 73 74 69 6e 67 00                          testing.    backtrace (crc 5eab668b):      [\u0026lt;0000000001e3714d\u0026gt;] kmemleak_alloc+0x34/0x40      [\u0026lt;000000006e6c7776\u0026gt;] __kmalloc_node_track_caller_noprof+0x300/0x3e0      [\u0026lt;000000006870467c\u0026gt;] kmemdup_noprof+0x34/0x60      [\u0026lt;000000001176bb03\u0026gt;] aa_unpack_strdup+0xd0/0x18c      [\u0026lt;0000000046a45c1a\u0026gt;] policy_unpack_test_unpack_strdup_with_name+0xd0/0x3c4      [\u0026lt;0000000032ef8f77\u0026gt;] kunit_try_run_case+0x13c/0x3ac      [\u0026lt;00000000f3edea23\u0026gt;] kunit_generic_run_threadfn_adapter+0x80/0xec      [\u0026lt;00000000adf936cf\u0026gt;] kthread+0x2e8/0x374      [\u0026lt;0000000041bb1628\u0026gt;] ret_from_fork+0x10/0x20(CVE-2024-56741)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()  syzbot reports deadlock issue of f2fs as below:  ====================================================== WARNING: possible circular locking dependency detected 6.12.0-rc3-syzkaller-00087-gc964ced77262 #0 Not tainted ------------------------------------------------------ kswapd0/79 is trying to acquire lock: ffff888011824088 (\u0026amp;sbi-\u0026gt;sb_lock){++++}-{3:3}, at: f2fs_down_write fs/f2fs/f2fs.h:2199 [inline] ffff888011824088 (\u0026amp;sbi-\u0026gt;sb_lock){++++}-{3:3}, at: f2fs_record_stop_reason+0x52/0x1d0 fs/f2fs/super.c:4068  but task is already holding lock: ffff88804bd92610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842  which lock already depends on the new lock.  the existing dependency chain (in reverse order) is:  -\u0026gt; #2 (sb_internal#2){.+.+}-{0:0}:        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825        percpu_down_read include/linux/percpu-rwsem.h:51 [inline]        __sb_start_write include/linux/fs.h:1716 [inline]        sb_start_intwrite+0x4d/0x1c0 include/linux/fs.h:1899        f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842        evict+0x4e8/0x9b0 fs/inode.c:725        f2fs_evict_inode+0x1a4/0x15c0 fs/f2fs/inode.c:807        evict+0x4e8/0x9b0 fs/inode.c:725        dispose_list fs/inode.c:774 [inline]        prune_icache_sb+0x239/0x2f0 fs/inode.c:963        super_cache_scan+0x38c/0x4b0 fs/super.c:223        do_shrink_slab+0x701/0x1160 mm/shrinker.c:435        shrink_slab+0x1093/0x14d0 mm/shrinker.c:662        shrink_one+0x43b/0x850 mm/vmscan.c:4818        shrink_many mm/vmscan.c:4879 [inline]        lru_gen_shrink_node mm/vmscan.c:4957 [inline]        shrink_node+0x3799/0x3de0 mm/vmscan.c:5937        kswapd_shrink_node mm/vmscan.c:6765 [inline]        balance_pgdat mm/vmscan.c:6957 [inline]        kswapd+0x1ca3/0x3700 mm/vmscan.c:7226        kthread+0x2f0/0x390 kernel/kthread.c:389        ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147        ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  -\u0026gt; #1 (fs_reclaim){+.+.}-{0:0}:        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825        __fs_reclaim_acquire mm/page_alloc.c:3834 [inline]        fs_reclaim_acquire+0x88/0x130 mm/page_alloc.c:3848        might_alloc include/linux/sched/mm.h:318 [inline]        prepare_alloc_pages+0x147/0x5b0 mm/page_alloc.c:4493        __alloc_pages_noprof+0x16f/0x710 mm/page_alloc.c:4722        alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265        alloc_pages_noprof mm/mempolicy.c:2345 [inline]        folio_alloc_noprof+0x128/0x180 mm/mempolicy.c:2352        filemap_alloc_folio_noprof+0xdf/0x500 mm/filemap.c:1010        do_read_cache_folio+0x2eb/0x850 mm/filemap.c:3787        read_mapping_folio include/linux/pagemap.h:1011 [inline]        f2fs_commit_super+0x3c0/0x7d0 fs/f2fs/super.c:4032        f2fs_record_stop_reason+0x13b/0x1d0 fs/f2fs/super.c:4079        f2fs_handle_critical_error+0x2ac/0x5c0 fs/f2fs/super.c:4174        f2fs_write_inode+0x35f/0x4d0 fs/f2fs/inode.c:785        write_inode fs/fs-writeback.c:1503 [inline]        __writeback_single_inode+0x711/0x10d0 fs/fs-writeback.c:1723        writeback_single_inode+0x1f3/0x660 fs/fs-writeback.c:1779        sync_inode_metadata+0xc4/0x120 fs/fs-writeback.c:2849        f2fs_release_file+0xa8/0x100 fs/f2fs/file.c:1941        __fput+0x23f/0x880 fs/file_table.c:431        task_work_run+0x24f/0x310 kernel/task_work.c:228        resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]        exit_to_user_mode_loop kernel/entry/common.c:114 [inline]        exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]        __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]        syscall_exit_to_user_mode+0x168/0x370 kernel/entry/common.c:218        do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89        entry_SYSCALL_64_after_hwframe+0x77/0x7f ---truncated---(CVE-2024-56744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()  Hook \u0026quot;qed_ops-\u0026gt;common-\u0026gt;sb_init = qed_sb_init\u0026quot; does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().(CVE-2024-56748)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()  When the call to gf100_grctx_generate() fails, unlock gr-\u0026gt;fecs.mutex before returning the error.  Fixes smatch warning:  drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: inconsistent returns \u0026apos;\u0026amp;gr-\u0026gt;fecs.mutex\u0026apos;.(CVE-2024-56752)","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-73.0.0.77.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","kernel-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","perf-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-73.0.0.77.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-73.0.0.77.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","kernel-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","perf-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-73.0.0.77.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1032"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49034"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49906"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53114"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53126"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53127"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53134"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53136"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53146"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53147"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53151"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53154"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53161"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53163"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53165"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53170"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53173"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53186"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53197"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53202"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53217"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53221"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53227"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53230"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56538"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56548"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56569"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56575"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56578"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56581"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56584"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56598"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56604"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56608"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56615"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56620"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56624"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56627"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56629"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56630"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56665"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56675"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56681"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56683"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56692"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56693"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56700"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56702"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56708"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56709"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56741"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56744"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56748"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56752"}],"database_specific":{"severity":"High"}}