Vulnerability-Lookup

URL	Tags
https://git.kernel.org/stable/c/baccb5e12577b7a9e…
https://git.kernel.org/stable/c/f57725bcc5816425e…
https://git.kernel.org/stable/c/e8a2b1c1c2ea85e9a…
https://git.kernel.org/stable/c/06cbfbb13ac88f415…
https://git.kernel.org/stable/c/3d7bda75e1a6239db…
https://git.kernel.org/stable/c/21900e8478126ff6a…
https://git.kernel.org/stable/c/2667c9b7b76efcbc7…
https://git.kernel.org/stable/c/bfeecda050aa9376f…
https://git.kernel.org/stable/c/1c82587cb57687de3…
https://lists.debian.org/debian-lts-announce/2025…
https://lists.debian.org/debian-lts-announce/2025…

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 6596528e391ad978a6a120142cba97a1d7324cb6 , < baccb5e12577b7a9eff54ffba301fdaa0f3ee5a8 (git) Affected: 6596528e391ad978a6a120142cba97a1d7324cb6 , < f57725bcc5816425e25218fdf5fb6923bc578cdf (git) Affected: 6596528e391ad978a6a120142cba97a1d7324cb6 , < e8a2b1c1c2ea85e9a5a2d0c5a5a7e7c639feb866 (git) Affected: 6596528e391ad978a6a120142cba97a1d7324cb6 , < 06cbfbb13ac88f4154c2eb4bc4176f9d10139847 (git) Affected: 6596528e391ad978a6a120142cba97a1d7324cb6 , < 3d7bda75e1a6239db053c73acde17ca146317824 (git) Affected: 6596528e391ad978a6a120142cba97a1d7324cb6 , < 21900e8478126ff6afe3b66679f676e74d1f8830 (git) Affected: 6596528e391ad978a6a120142cba97a1d7324cb6 , < 2667c9b7b76efcbc7adbfea249892f20c313b0da (git) Affected: 6596528e391ad978a6a120142cba97a1d7324cb6 , < bfeecda050aa9376f642d5b2a71c4112cc6c8216 (git) Affected: 6596528e391ad978a6a120142cba97a1d7324cb6 , < 1c82587cb57687de3f18ab4b98a8850c789bedcf (git) Affected: c53c89aba3ebdfc3e9acdb18bb5ee9d2f8a328d0 (git) Affected: 3.0.8 , < 3.1 (semver)	guessed
Linux	Linux	Affected: 3.1 Unaffected: 0 , < 3.1 (semver) Unaffected: 4.19.325 , ≤ 4.19.* (semver) Unaffected: 5.4.287 , ≤ 5.4.* (semver) Unaffected: 5.10.231 , ≤ 5.10.* (semver) Unaffected: 5.15.174 , ≤ 5.15.* (semver) Unaffected: 6.1.120 , ≤ 6.1.* (semver) Unaffected: 6.6.64 , ≤ 6.6.* (semver) Unaffected: 6.11.11 , ≤ 6.11.* (semver) Unaffected: 6.12.2 , ≤ 6.12.* (semver) Unaffected: 6.13 , ≤ * (original_commit_for_fix)	guessed

OESA-2025-1035 (CVE-2022-49002)

Vulnerability from osv_openeuler – Published: 2025-01-10 11:08 – Updated: 2026-08-06 11:08 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak.(CVE-2022-49002)

In 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] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---(CVE-2022-49034)

In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case.(CVE-2022-49035)

In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.(CVE-2024-47730)

In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on a node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.(CVE-2024-49856)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing "dc" to "dc->hwss.apply_idle_power_optimizations", which dereferences null "dc->clk_mgr". (The function pointer resolves to "dcn35_apply_idle_power_optimizations".) This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49907)

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.(CVE-2024-50001)

In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.(CVE-2024-50188)

In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.(CVE-2024-50233)

In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.(CVE-2024-50264)

In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.(CVE-2024-50287)

In 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->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)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix uninitialized value in ocfs2_file_read_iter() Syzbot has reported the following KMSAN splat: BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30 Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 slaballoc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Since an instance of 'struct kiocb' may be passed from the block layer with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()' and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in 'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.(CVE-2024-53155)

In the Linux kernel, the following vulnerability has been resolved: soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get() This loop is supposed to break if the frequency returned from clk_round_rate() is the same as on the previous iteration. However, that check doesn't make sense on the first iteration through the loop. It leads to reading before the start of these->clk_perf_tbl[] array.(CVE-2024-53158)

In the Linux kernel, the following vulnerability has been resolved: EDAC/bluefield: Fix potential integer overflow The 64-bit argument for the "get DIMM info" 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)

In 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's only add it to the list after everything has succeeded.(CVE-2024-53165)

In the Linux kernel, the following vulnerability has been resolved: ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit After an insertion in TNC, the tree might split and cause a node to change its znode->parent. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node's znode->cparent could still point to a freed node. This znode->cparent may not be updated when getting nodes to commit in ubifs_tnc_start_commit(). This could then trigger a use-after-free when accessing the znode->cparent in write_index() in ubifs_tnc_end_commit(). This can be triggered by running rm -f /etc/test-file.bin dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync in a loop, and with CONFIG_UBIFS_FS_AUTHENTICATION. KASAN then reports: BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950 Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153 Call trace: dump_backtrace+0x0/0x340 show_stack+0x18/0x24 dump_stack_lvl+0x9c/0xbc print_address_description.constprop.0+0x74/0x2b0 kasan_report+0x1d8/0x1f0 kasan_check_range+0xf8/0x1a0 memcpy+0x84/0xf4 ubifs_tnc_end_commit+0xa5c/0x1950 do_commit+0x4e0/0x1340 ubifs_bg_thread+0x234/0x2e0 kthread+0x36c/0x410 ret_from_fork+0x10/0x20 Allocated by task 401: kasan_save_stack+0x38/0x70 __kasan_kmalloc+0x8c/0xd0 __kmalloc+0x34c/0x5bc tnc_insert+0x140/0x16a4 ubifs_tnc_add+0x370/0x52c ubifs_jnl_write_data+0x5d8/0x870 do_writepage+0x36c/0x510 ubifs_writepage+0x190/0x4dc __writepage+0x58/0x154 write_cache_pages+0x394/0x830 do_writepages+0x1f0/0x5b0 filemap_fdatawrite_wbc+0x170/0x25c file_write_and_wait_range+0x140/0x190 ubifs_fsync+0xe8/0x290 vfs_fsync_range+0xc0/0x1e4 do_fsync+0x40/0x90 __arm64_sys_fsync+0x34/0x50 invoke_syscall.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 Freed by task 403: kasan_save_stack+0x38/0x70 kasan_set_track+0x28/0x40 kasan_set_free_info+0x28/0x4c __kasan_slab_free+0xd4/0x13c kfree+0xc4/0x3a0 tnc_delete+0x3f4/0xe40 ubifs_tnc_remove_range+0x368/0x73c ubifs_tnc_remove_ino+0x29c/0x2e0 ubifs_jnl_delete_inode+0x150/0x260 ubifs_evict_inode+0x1d4/0x2e4 evict+0x1c8/0x450 iput+0x2a0/0x3c4 do_unlinkat+0x2cc/0x490 __arm64_sys_unlinkat+0x90/0x100 invoke_syscall.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 The offending memcpy() in ubifs_copy_hash() has a use-after-free when a node becomes root in TNC but still has a cparent to an already freed node. More specifically, consider the following TNC: zroot / / zp1 / / zn Inserting a new node zn_new with a key smaller then zn will trigger a split in tnc_insert() if zp1 is full: zroot / \ / \ zp1 zp2 / \ / \ zn_new zn zn->parent has now been moved to zp2, but zn->cparent still points to zp1. Now, consider a removal of all the nodes except zn. Just when tnc_delete() is about to delete zroot and zp2: zroot \ \ zp2 \ \ zn zroot and zp2 get freed and the tree collapses: zn zn now becomes the new zroot. get_znodes_to_commit() will now only find zn, the new zroot, and write_index() will check its znode->cparent that wrongly points to the already freed zp1. ubifs_copy_hash() thus gets wrongly called with znode->cparent->zbranch[znode->iip].hash that triggers the use-after-free! Fix this by explicitly setting znode->cparent to NULL in get_znodes_to_commit() for the root node. The search for the dirty nodes ---truncated---(CVE-2024-53171)

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix NULL ptr deref in crypto_aead_setkey() Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher. See MS-SMB2 3.3.5.4. Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added a @server->cipher_type check to conditionally call smb3_crypto_aead_allocate(), but that check would always be false as @server->cipher_type is unset for SMB3.02. Fix the following KASAN splat by setting @server->cipher_type for SMB3.02 as well. mount.cifs //srv/share /mnt -o vers=3.02,seal,... BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfxlockacquire+0x10/0x10 ? pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53185)

In the Linux kernel, the following vulnerability has been resolved: io_uring: check for overflows in io_pin_pages WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: <TASK> __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... </TASK> io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.(CVE-2024-53187)

In the Linux kernel, the following vulnerability has been resolved: PCI: Fix use-after-free of slot->bus on hot remove Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock. Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver. The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock. The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is never acquired. The pci_bus is destroyed before the pci_slot, so a use-after-free ensues when pci_slot_release() accesses slot->bus. In principle this should not happen because pci_stop_bus_device() unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by pci_remove_bus_device(). However the stacktrace provided by Dennis shows that pciehp is unbound from pci_remove_bus_device() instead of pci_stop_bus_device(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in pci_remove_bus_device(). There is no precaution to prevent driver binding in-between pci_stop_bus_device() and pci_remove_bus_device(). In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pci_bus_add_devices(). pciehp is bound to the Downstream Port after pci_stop_bus_device() has run, so it is unbound by pci_remove_bus_device() instead of pci_stop_bus_device(). Because the pci_bus has already been destroyed at that point, accesses to it result in a use-after-free. One might conclude that driver binding needs to be prevented after pci_stop_bus_device() has run. However it seems risky that pci_slot points to pci_bus without holding a reference. Solely relying on correct ordering of driver unbind versus pci_bus destruction is certainly not defensive programming. If pci_slot has a need to access data in pci_bus, it ought to acquire a reference. Amend pci_create_slot() accordingly. Dennis reports that the crash is not reproducible with this change. Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 pci_destroy_slot pciehp_remove pcie_port_remove_service device_release_driver_internal bus_remove_device device_del device_unregister remove_iter device_for_each_child pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_device (recursive invocation) pci_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist(CVE-2024-53194)

In 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->config. This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration.(CVE-2024-53197)

In the Linux kernel, the following vulnerability has been resolved: virtiofs: use pages instead of pointer for kernel direct IO When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: <TASK> ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... </TASK> ---[ end trace 0000000000000000 ]--- The warning is triggered as follows: 1) syscall finit_module() handles the module insertion and it invokes kernel_read_file() to read the content of the module first. 2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and passes it to kernel_read(). kernel_read() constructs a kvec iter by using iov_iter_kvec() and passes it to fuse_file_read_iter(). 3) virtio-fs disables the cache, so fuse_file_read_iter() invokes fuse_direct_io(). As for now, the maximal read size for kvec iter is only limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, so fuse_direct_io() doesn't split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in out_args[0] of a fuse request and passes the fuse request to virtio_fs_wake_pending_and_unlock(). 4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to queue the request. Because virtiofs need DMA-able address, so virtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL; 5) virtio_fs_enqueue_req() will retry the memory allocation in a kworker, but it won't help, because kmalloc() will always return NULL due to the abnormal size and finit_module() will hang forever. A feasible solution is to limit the value of max_read for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc->max_write in kernel. So instead of limiting both the values of max_read and max_write in kernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as true in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use pages instead of pointer to pass the KVEC_IO data. After switching to pages for KVEC_IO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}_kernel_vmap_range() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuse_args_pages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fuse_get_user_pages() for write operations and the invalidation in fuse_release_user_pages() for read operations. It may seem necessary to introduce another fie ---truncated---(CVE-2024-53219)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null-ptr-deref in f2fs_submit_page_bio() There'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: <TASK> 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 "f2fs_fs_type". To address above issue just register "f2fs_fs_type" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized.(CVE-2024-53221)

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Move events notifier registration to be after device registration Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events. Fix a race between the device deregistration and pkey change work by moving MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkey_change_handler [mlx5_ib] RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib] process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x380/0x380 kthread+0x149/0x170 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]---(CVE-2024-53224)

In 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: <TASK> 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 </TASK> 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); --> Trigger double release Don't call bfad_im_module_exit() if bfad_im_module_init() failed.(CVE-2024-53227)

In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Release resources at card release The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort(). But at this moment, the card object might be still in use (as we're calling snd_card_free_when_closed()). For avoid potential UAFs, move the release of resources to the card's private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback.(CVE-2024-53239)

In 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's internals.(CVE-2024-56538)

In the Linux kernel, the following vulnerability has been resolved: hfsplus: don'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] <TASK> [ 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 <48> 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)

In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs() if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check "init_dyn_addr" i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free "dyn_addr" Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".(CVE-2024-56562)

In the Linux kernel, the following vulnerability has been resolved: ad7780: fix division by zero in ad7780_write_raw() In the ad7780_write_raw() , val2 can be zero, which might lead to a division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw() is based on iio_info's write_raw. While val is explicitly declared that can be zero (in read mode), val2 is not specified to be non-zero.(CVE-2024-56567)

In 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 "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filter The current mod command causes a null pointer dereference. While commit 0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter") has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash.(CVE-2024-56569)

In the Linux kernel, the following vulnerability has been resolved: ovl: Filter invalid inodes with missing lookup function Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack.(CVE-2024-56570)

In 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 'ref') into the respective block entry's rbtree (local variable 'be'), 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'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'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)

In the Linux kernel, the following vulnerability has been resolved: sched/deadline: Fix warning in migrate_enable for boosted tasks When running the following command: while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quiet done a warning is eventually triggered: WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794 setup_new_dl_entity+0x13e/0x180 ... Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? enqueue_dl_entity+0x631/0x6e0 ? setup_new_dl_entity+0x13e/0x180 ? __warn+0x7e/0xd0 ? report_bug+0x11a/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 enqueue_dl_entity+0x631/0x6e0 enqueue_task_dl+0x7d/0x120 __do_set_cpus_allowed+0xe3/0x280 __set_cpus_allowed_ptr_locked+0x140/0x1d0 __set_cpus_allowed_ptr+0x54/0xa0 migrate_enable+0x7e/0x150 rt_spin_unlock+0x1c/0x90 group_send_sig_info+0xf7/0x1a0 ? kill_pid_info+0x1f/0x1d0 kill_pid_info+0x78/0x1d0 kill_proc_info+0x5b/0x110 __x64_sys_kill+0x93/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92b This warning occurs because set_cpus_allowed dequeues and enqueues tasks with the ENQUEUE_RESTORE flag set. If the task is boosted, the warning is triggered. A boosted task already had its parameters set by rt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary, hence the WARN_ON call. Check if we are requeueing a boosted task and avoid calling setup_new_dl_entity if that's the case.(CVE-2024-56583)

In 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(&tctx->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 ->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)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode. creating a large files during checkpoint disable until it runs out of space and then delete it, then remount to enable checkpoint again, and then unmount the filesystem triggers the f2fs_bug_on as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/inode.c:896! CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360 Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:f2fs_evict_inode+0x58c/0x610 Call Trace: __die_body+0x15/0x60 die+0x33/0x50 do_trap+0x10a/0x120 f2fs_evict_inode+0x58c/0x610 do_error_trap+0x60/0x80 f2fs_evict_inode+0x58c/0x610 exc_invalid_op+0x53/0x60 f2fs_evict_inode+0x58c/0x610 asm_exc_invalid_op+0x16/0x20 f2fs_evict_inode+0x58c/0x610 evict+0x101/0x260 dispose_list+0x30/0x50 evict_inodes+0x140/0x190 generic_shutdown_super+0x2f/0x150 kill_block_super+0x11/0x40 kill_f2fs_super+0x7d/0x140 deactivate_locked_super+0x2a/0x70 cleanup_mnt+0xb3/0x140 task_work_run+0x61/0x90 The root cause is: creating large files during disable checkpoint period results in not enough free segments, so when writing back root inode will failed in f2fs_enable_checkpoint. When umount the file system after enabling checkpoint, the root inode is dirty in f2fs_evict_inode function, which triggers BUG_ON. The steps to reproduce are as follows: dd if=/dev/zero of=f2fs.img bs=1M count=55 mount f2fs.img f2fs_dir -o checkpoint=disable:10% dd if=/dev/zero of=big bs=1M count=50 sync rm big mount -o remount,checkpoint=enable f2fs_dir umount f2fs_dir Let's redirty inode when there is not free segments during checkpoint is disable.(CVE-2024-56586)

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: set the right AMDGPU sg segment limitation The driver needs to set the correct max_segment_size; otherwise debug_dma_map_sg() will complain about the over-mapping of the AMDGPU sg length as following: WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370 [ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd [ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492 [ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370 [ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05 [ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286 [ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027 [ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680 [ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930 [ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000 [ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800 [ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000 [ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0 [ 364.049605] Call Trace: [ 364.049607] <TASK> [ 364.049609] ? show_regs+0x6d/0x80 [ 364.049614] ? __warn+0x8c/0x140 [ 364.049618] ? debug_dma_map_sg+0x2dc/0x370 [ 364.049621] ? report_bug+0x193/0x1a0 [ 364.049627] ? handle_bug+0x46/0x80 [ 364.049631] ? exc_invalid_op+0x1d/0x80 [ 364.049635] ? asm_exc_invalid_op+0x1f/0x30 [ 364.049642] ? debug_dma_map_sg+0x2dc/0x370 [ 364.049647] __dma_map_sg_attrs+0x90/0xe0 [ 364.049651] dma_map_sgtable+0x25/0x40 [ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu] [ 364.049935] ? srso_return_thunk+0x5/0x5f [ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu] [ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm] [ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm] [ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu] [ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu] [ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu] [ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu] [ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu] [ 364.05105 ---truncated---(CVE-2024-56594)

In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in jfs_readdir The stbl might contain some invalid values. Added a check to return error code in that case.(CVE-2024-56596)

In 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)

In 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)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create() bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code.(CVE-2024-56605)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bounds access in 'dcn21_link_encoder_create' 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'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 'dcn10_link_enc_hpd_registers [5]' [ 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] <TASK> [ 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] ? __pfxdriverattach+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 <48> 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] </TASK> [ 65.923927] ---[ end trace ]---(CVE-2024-56608)

In 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 <48> 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] <TASK> [ 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] </TASK>(CVE-2024-56615)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry() Syzbot reported that when searching for records in a directory where the inode's i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled. This is because nilfs_last_byte(), which is called by nilfs_find_entry() and others to calculate the number of valid bytes of directory data in a page from i_size and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the i_size value is assigned. This caused a large byte offset value due to underflow in the end address calculation in the calling nilfs_find_entry(), resulting in memory access that exceeds the folio/page size. Fix this issue by changing the type of the local variable causing the bit loss from "unsigned int" to "u64". The return value of nilfs_last_byte() is also of type "unsigned int", but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required.(CVE-2024-56619)

In 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 'vfs objects = streams_xattr parameter' in ksmbd.conf.(CVE-2024-56627)

In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix when get product name maybe null pointer Due to incorrect dev->product reporting by certain devices, null pointer dereferences occur when dev->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)

In 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 ("ocfs2: Handle error from dquot_initialize()") forgot to call iput() when new_inode() succeeded and dquot_initialize() failed.(CVE-2024-56630)

In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix UAF in blkcg_unpin_online() blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcg_parent(blkcg) but it was calling that after blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF: ================================================================== BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> ... Freed by task 1944: kasan_save_track+0x2b/0x70 kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50 kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcg_unpin_online(). Fix it by reading the parent pointer before destroying the blkcg's blkg's.(CVE-2024-56672)

In 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)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix race in buffer_head read fault injection When I enabled ext4 debug for fault injection testing, I encountered the following warning: EXT4-fs error (device sda): ext4_read_inode_bitmap:201: comm fsstress: Cannot read inode bitmap - block_group = 8, inode_bitmap = 1051 WARNING: CPU: 0 PID: 511 at fs/buffer.c:1181 mark_buffer_dirty+0x1b3/0x1d0 The root cause of the issue lies in the improper implementation of ext4's buffer_head read fault injection. The actual completion of buffer_head read and the buffer_head fault injection are not atomic, which can lead to the uptodate flag being cleared on normally used buffer_heads in race conditions. [CPU0] [CPU1] [CPU2] ext4_read_inode_bitmap ext4_read_bh() <bh read complete> ext4_read_inode_bitmap if (buffer_uptodate(bh)) return bh jbd2_journal_commit_transaction __jbd2_journal_refile_buffer __jbd2_journal_unfile_buffer __jbd2_journal_temp_unlink_buffer ext4_simulate_fail_bh() clear_buffer_uptodate mark_buffer_dirty <report warning> WARN_ON_ONCE(!buffer_uptodate(bh)) The best approach would be to perform fault injection in the IO completion callback function, rather than after IO completion. However, the IO completion callback function cannot get the fault injection code in sb. Fix it by passing the result of fault injection into the bh read function, we simulate faults within the bh read function itself. This requires adding an extra parameter to the bh read functions that need fault injection.(CVE-2024-56686)

In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56691)

In 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's add sanity check on nat blkaddr in truncate_node().(CVE-2024-56692)

In 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->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->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)

In 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's the final task_work run or the fallback path. In this case, task work will find ->io_wq being already killed and null'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 ->iowq check would race.(CVE-2024-56709)

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix cpu stuck caused by printings during reset During reset, cmd to destroy resources such as qp, cq, and mr may fail, and error logs will be printed. When a large number of resources are destroyed, there will be lots of printings, and it may lead to a cpu stuck. Delete some unnecessary printings and replace other printing functions in these paths with the ratelimited version.(CVE-2024-56722)

In the Linux kernel, the following vulnerability has been resolved: rtc: check if __rtc_read_time was successful in rtc_timer_do_work() If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup.(CVE-2024-56739)

In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb() Hook "qedi_ops->common->sb_init = qed_sb_init" 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-56747)

In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb() Hook "qed_ops->common->sb_init = qed_sb_init" 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)

In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix freeing of the HMB descriptor table The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent. In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page.(CVE-2024-56756)

In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent bad count for tracing_cpumask_write If a large count is provided, it will trigger a warning in bitmap_parse_user. Also check zero for it.(CVE-2024-56763)

Severity

8.0 (High)


                    
                      CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49002	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49034	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49035	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-47730	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49856	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49907	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50001	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50188	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50233	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50264	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50287	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53147	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53155	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53158	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53161	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53165	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53171	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53185	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53187	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53194	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53197	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53219	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53221	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53224	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53227	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53239	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56538	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56548	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56562	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56567	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56569	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56570	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56581	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56583	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56584	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56586	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56594	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56596	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56598	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56604	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56605	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56608	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56615	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56619	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56627	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56629	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56630	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56672	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56681	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56686	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56691	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56692	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56700	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56709	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56722	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56739	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56747	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56748	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56756	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56763	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.108.0.188.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.108.0.188.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.108.0.188.oe2203sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-136.108.0.188.oe2203sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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:  iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()  for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL.  If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak.(CVE-2022-49002)\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:  media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE  I expect that the hardware will have limited this to 16, but just in case it hasn\u0026apos;t, check for this corner case.(CVE-2022-49035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  crypto: hisilicon/qm - inject error before stopping queue  The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.(CVE-2024-47730)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/sgx: Fix deadlock in SGX NUMA node search  When the current node doesn\u0026apos;t have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask.  Also worth mentioning is that it\u0026apos;s perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality.  Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.(CVE-2024-49856)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before using dc-\u0026gt;clk_mgr  [WHY \u0026amp; HOW] dc-\u0026gt;clk_mgr is null checked previously in the same function, indicating it might be null.  Passing \u0026quot;dc\u0026quot; to \u0026quot;dc-\u0026gt;hwss.apply_idle_power_optimizations\u0026quot;, which dereferences null \u0026quot;dc-\u0026gt;clk_mgr\u0026quot;. (The function pointer resolves to \u0026quot;dcn35_apply_idle_power_optimizations\u0026quot;.)  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49907)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/mlx5: Fix error path in multi-packet WQE transmit  Remove the erroneous unmap in case no DMA mapping was established  The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can\u0026apos;t allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq\u0026apos;s FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state.  The erroneous behavior was seen in a stress-test environment that created memory pressure.(CVE-2024-50001)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: phy: dp83869: fix memory corruption when enabling fiber  When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 \u0026lt;\u0026lt; 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure.  Since the advertising flags are updated from supported at the end of the function the incorrect line isn\u0026apos;t needed at all and can be removed.(CVE-2024-50188)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()  In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout \u0026gt; (clk_get_rate(st-\u0026gt;mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.(CVE-2024-50233)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vsock/virtio: Initialization of the dangling pointer occurring in vsk-\u0026gt;trans  During loopback communication, a dangling pointer can be created in vsk-\u0026gt;trans, potentially leading to a Use-After-Free condition.  This issue is resolved by initializing vsk-\u0026gt;trans to NULL.(CVE-2024-50264)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: v4l2-tpg: prevent the risk of a division by zero  As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero.  Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.(CVE-2024-50287)\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:  ocfs2: fix uninitialized value in ocfs2_file_read_iter()  Syzbot has reported the following KMSAN splat:  BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80  ocfs2_file_read_iter+0x9a4/0xf80  __io_read+0x8d4/0x20f0  io_read+0x3e/0xf0  io_issue_sqe+0x42b/0x22c0  io_wq_submit_work+0xaf9/0xdc0  io_worker_handle_work+0xd13/0x2110  io_wq_worker+0x447/0x1410  ret_from_fork+0x6f/0x90  ret_from_fork_asm+0x1a/0x30  Uninit was created at:  __alloc_pages_noprof+0x9a7/0xe00  alloc_pages_mpol_noprof+0x299/0x990  alloc_pages_noprof+0x1bf/0x1e0  allocate_slab+0x33a/0x1250  ___slab_alloc+0x12ef/0x35e0  kmem_cache_alloc_bulk_noprof+0x486/0x1330  __io_alloc_req_refill+0x84/0x560  io_submit_sqes+0x172f/0x2f30  __se_sys_io_uring_enter+0x406/0x41c0  __x64_sys_io_uring_enter+0x11f/0x1a0  x64_sys_call+0x2b54/0x3ba0  do_syscall_64+0xcd/0x1e0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Since an instance of \u0026apos;struct kiocb\u0026apos; may be passed from the block layer with \u0026apos;private\u0026apos; field uninitialized, introduce \u0026apos;ocfs2_iocb_init_rw_locked()\u0026apos; and use it from where \u0026apos;ocfs2_dio_end_io()\u0026apos; might take care, i.e. in \u0026apos;ocfs2_file_read_iter()\u0026apos; and \u0026apos;ocfs2_file_write_iter()\u0026apos;.(CVE-2024-53155)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()  This loop is supposed to break if the frequency returned from clk_round_rate() is the same as on the previous iteration.  However, that check doesn\u0026apos;t make sense on the first iteration through the loop. It leads to reading before the start of these-\u0026gt;clk_perf_tbl[] array.(CVE-2024-53158)\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:  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:  ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit  After an insertion in TNC, the tree might split and cause a node to change its `znode-\u0026gt;parent`. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node\u0026apos;s `znode-\u0026gt;cparent` could still point to a freed node. This `znode-\u0026gt;cparent` may not be updated when getting nodes to commit in `ubifs_tnc_start_commit()`. This could then trigger a use-after-free when accessing the `znode-\u0026gt;cparent` in `write_index()` in `ubifs_tnc_end_commit()`.  This can be triggered by running    rm -f /etc/test-file.bin   dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync  in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then reports:    BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950   Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153    Call trace:    dump_backtrace+0x0/0x340    show_stack+0x18/0x24    dump_stack_lvl+0x9c/0xbc    print_address_description.constprop.0+0x74/0x2b0    kasan_report+0x1d8/0x1f0    kasan_check_range+0xf8/0x1a0    memcpy+0x84/0xf4    ubifs_tnc_end_commit+0xa5c/0x1950    do_commit+0x4e0/0x1340    ubifs_bg_thread+0x234/0x2e0    kthread+0x36c/0x410    ret_from_fork+0x10/0x20    Allocated by task 401:    kasan_save_stack+0x38/0x70    __kasan_kmalloc+0x8c/0xd0    __kmalloc+0x34c/0x5bc    tnc_insert+0x140/0x16a4    ubifs_tnc_add+0x370/0x52c    ubifs_jnl_write_data+0x5d8/0x870    do_writepage+0x36c/0x510    ubifs_writepage+0x190/0x4dc    __writepage+0x58/0x154    write_cache_pages+0x394/0x830    do_writepages+0x1f0/0x5b0    filemap_fdatawrite_wbc+0x170/0x25c    file_write_and_wait_range+0x140/0x190    ubifs_fsync+0xe8/0x290    vfs_fsync_range+0xc0/0x1e4    do_fsync+0x40/0x90    __arm64_sys_fsync+0x34/0x50    invoke_syscall.constprop.0+0xa8/0x260    do_el0_svc+0xc8/0x1f0    el0_svc+0x34/0x70    el0t_64_sync_handler+0x108/0x114    el0t_64_sync+0x1a4/0x1a8    Freed by task 403:    kasan_save_stack+0x38/0x70    kasan_set_track+0x28/0x40    kasan_set_free_info+0x28/0x4c    __kasan_slab_free+0xd4/0x13c    kfree+0xc4/0x3a0    tnc_delete+0x3f4/0xe40    ubifs_tnc_remove_range+0x368/0x73c    ubifs_tnc_remove_ino+0x29c/0x2e0    ubifs_jnl_delete_inode+0x150/0x260    ubifs_evict_inode+0x1d4/0x2e4    evict+0x1c8/0x450    iput+0x2a0/0x3c4    do_unlinkat+0x2cc/0x490    __arm64_sys_unlinkat+0x90/0x100    invoke_syscall.constprop.0+0xa8/0x260    do_el0_svc+0xc8/0x1f0    el0_svc+0x34/0x70    el0t_64_sync_handler+0x108/0x114    el0t_64_sync+0x1a4/0x1a8  The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free when a node becomes root in TNC but still has a `cparent` to an already freed node. More specifically, consider the following TNC:           zroot          /         /       zp1       /      /     zn  Inserting a new node `zn_new` with a key smaller then `zn` will trigger a split in `tnc_insert()` if `zp1` is full:           zroot          /   \\         /     \\       zp1     zp2       /         \\      /           \\   zn_new          zn  `zn-\u0026gt;parent` has now been moved to `zp2`, *but* `zn-\u0026gt;cparent` still points to `zp1`.  Now, consider a removal of all the nodes _except_ `zn`. Just when `tnc_delete()` is about to delete `zroot` and `zp2`:           zroot              \\               \\               zp2                 \\                  \\                  zn  `zroot` and `zp2` get freed and the tree collapses:             zn  `zn` now becomes the new `zroot`.  `get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and `write_index()` will check its `znode-\u0026gt;cparent` that wrongly points to the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called with `znode-\u0026gt;cparent-\u0026gt;zbranch[znode-\u0026gt;iip].hash` that triggers the use-after-free!  Fix this by explicitly setting `znode-\u0026gt;cparent` to `NULL` in `get_znodes_to_commit()` for the root node. The search for the dirty nodes ---truncated---(CVE-2024-53171)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  smb: client: fix NULL ptr deref in crypto_aead_setkey()  Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher.  See MS-SMB2 3.3.5.4.  Commit b0abcd65ec54 (\u0026quot;smb: client: fix UAF in async decryption\u0026quot;) added a @server-\u0026gt;cipher_type check to conditionally call smb3_crypto_aead_allocate(), but that check would always be false as @server-\u0026gt;cipher_type is unset for SMB3.02.  Fix the following KASAN splat by setting @server-\u0026gt;cipher_type for SMB3.02 as well.  mount.cifs //srv/share /mnt -o vers=3.02,seal,...  BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  dump_stack_lvl+0x5d/0x80  ? crypto_aead_setkey+0x2c/0x130  kasan_report+0xda/0x110  ? crypto_aead_setkey+0x2c/0x130  crypto_aead_setkey+0x2c/0x130  crypt_message+0x258/0xec0 [cifs]  ? __asan_memset+0x23/0x50  ? __pfx_crypt_message+0x10/0x10 [cifs]  ? mark_lock+0xb0/0x6a0  ? hlock_class+0x32/0xb0  ? mark_lock+0xb0/0x6a0  smb3_init_transform_rq+0x352/0x3f0 [cifs]  ? lock_acquire.part.0+0xf4/0x2a0  smb_send_rqst+0x144/0x230 [cifs]  ? __pfx_smb_send_rqst+0x10/0x10 [cifs]  ? hlock_class+0x32/0xb0  ? smb2_setup_request+0x225/0x3a0 [cifs]  ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs]  compound_send_recv+0x59b/0x1140 [cifs]  ? __pfx_compound_send_recv+0x10/0x10 [cifs]  ? __create_object+0x5e/0x90  ? hlock_class+0x32/0xb0  ? do_raw_spin_unlock+0x9a/0xf0  cifs_send_recv+0x23/0x30 [cifs]  SMB2_tcon+0x3ec/0xb30 [cifs]  ? __pfx_SMB2_tcon+0x10/0x10 [cifs]  ? lock_acquire.part.0+0xf4/0x2a0  ? __pfx_lock_release+0x10/0x10  ? do_raw_spin_trylock+0xc6/0x120  ? lock_acquire+0x3f/0x90  ? _get_xid+0x16/0xd0 [cifs]  ? __pfx_SMB2_tcon+0x10/0x10 [cifs]  ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs]  cifs_get_smb_ses+0xcdd/0x10a0 [cifs]  ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs]  ? cifs_get_tcp_session+0xaa0/0xca0 [cifs]  cifs_mount_get_session+0x8a/0x210 [cifs]  dfs_mount_share+0x1b0/0x11d0 [cifs]  ? __pfx___lock_acquire+0x10/0x10  ? __pfx_dfs_mount_share+0x10/0x10 [cifs]  ? lock_acquire.part.0+0xf4/0x2a0  ? find_held_lock+0x8a/0xa0  ? hlock_class+0x32/0xb0  ? lock_release+0x203/0x5d0  cifs_mount+0xb3/0x3d0 [cifs]  ? do_raw_spin_trylock+0xc6/0x120  ? __pfx_cifs_mount+0x10/0x10 [cifs]  ? lock_acquire+0x3f/0x90  ? find_nls+0x16/0xa0  ? smb3_update_mnt_flags+0x372/0x3b0 [cifs]  cifs_smb3_do_mount+0x1e2/0xc80 [cifs]  ? __pfx_vfs_parse_fs_string+0x10/0x10  ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs]  smb3_get_tree+0x1bf/0x330 [cifs]  vfs_get_tree+0x4a/0x160  path_mount+0x3c1/0xfb0  ? kasan_quarantine_put+0xc7/0x1d0  ? __pfx_path_mount+0x10/0x10  ? kmem_cache_free+0x118/0x3e0  ? user_path_at+0x74/0xa0  __x64_sys_mount+0x1a6/0x1e0  ? __pfx___x64_sys_mount+0x10/0x10  ? mark_held_locks+0x1a/0x90  do_syscall_64+0xbb/0x1d0  entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53185)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  io_uring: check for overflows in io_pin_pages  WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace:  \u0026lt;TASK\u0026gt;  __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183  io_rings_map io_uring/io_uring.c:2611 [inline]  io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470  io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692  io_uring_setup io_uring/io_uring.c:3781 [inline]  ...  \u0026lt;/TASK\u0026gt;  io_pin_pages()\u0026apos;s uaddr parameter came directly from the user and can be garbage. Don\u0026apos;t just add size to it as it can overflow.(CVE-2024-53187)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  PCI: Fix use-after-free of slot-\u0026gt;bus on hot remove  Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.  Since commit 0fc70886569c (\u0026quot;thunderbolt: Reset USB4 v2 host router\u0026quot;) and commit 59a54c5f3dbd (\u0026quot;thunderbolt: Reset topology created by the boot firmware\u0026quot;), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver.  The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router\u0026apos;s Root Port and thus causes hot removal of the dock.  The crash occurs when pciehp is unbound from one of the dock\u0026apos;s Downstream Ports:  pciehp creates a pci_slot on bind and destroys it on unbind.  The pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is never acquired.  The pci_bus is destroyed before the pci_slot, so a use-after-free ensues when pci_slot_release() accesses slot-\u0026gt;bus.  In principle this should not happen because pci_stop_bus_device() unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by pci_remove_bus_device().  However the stacktrace provided by Dennis shows that pciehp is unbound from pci_remove_bus_device() instead of pci_stop_bus_device().  To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy:  It first unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in pci_remove_bus_device().  There is no precaution to prevent driver binding in-between pci_stop_bus_device() and pci_remove_bus_device().  In Dennis\u0026apos; case, it seems removal of the hierarchy by pciehp races with driver binding by pci_bus_add_devices().  pciehp is bound to the Downstream Port after pci_stop_bus_device() has run, so it is unbound by pci_remove_bus_device() instead of pci_stop_bus_device().  Because the pci_bus has already been destroyed at that point, accesses to it result in a use-after-free.  One might conclude that driver binding needs to be prevented after pci_stop_bus_device() has run.  However it seems risky that pci_slot points to pci_bus without holding a reference.  Solely relying on correct ordering of driver unbind versus pci_bus destruction is certainly not defensive programming.  If pci_slot has a need to access data in pci_bus, it ought to acquire a reference.  Amend pci_create_slot() accordingly.  Dennis reports that the crash is not reproducible with this change.  Abridged stacktrace:    pcieport 0000:00:07.0: PME: Signaling with IRQ 156   pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+   pci_bus 0000:20: dev 00, created physical slot 12   pcieport 0000:00:07.0: pciehp: Slot(12): Card not present   ...   pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0   Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI   CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1   RIP: 0010:dev_driver_string+0x12/0x40   pci_destroy_slot   pciehp_remove   pcie_port_remove_service   device_release_driver_internal   bus_remove_device   device_del   device_unregister   remove_iter   device_for_each_child   pcie_portdrv_remove   pci_device_remove   device_release_driver_internal   bus_remove_device   device_del   pci_remove_bus_device (recursive invocation)   pci_remove_bus_device   pciehp_unconfigure_device   pciehp_disable_slot   pciehp_handle_presence_or_link_change   pciehp_ist(CVE-2024-53194)\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:  virtiofs: use pages instead of pointer for kernel direct IO  When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported:    ------------[ cut here ]------------   WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ......   Modules linked in:   CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......   RIP: 0010:__alloc_pages+0x2bf/0x380   ......   Call Trace:    \u0026lt;TASK\u0026gt;    ? __warn+0x8e/0x150    ? __alloc_pages+0x2bf/0x380    __kmalloc_large_node+0x86/0x160    __kmalloc+0x33c/0x480    virtio_fs_enqueue_req+0x240/0x6d0    virtio_fs_wake_pending_and_unlock+0x7f/0x190    queue_request_and_unlock+0x55/0x60    fuse_simple_request+0x152/0x2b0    fuse_direct_io+0x5d2/0x8c0    fuse_file_read_iter+0x121/0x160    __kernel_read+0x151/0x2d0    kernel_read+0x45/0x50    kernel_read_file+0x1a9/0x2a0    init_module_from_file+0x6a/0xe0    idempotent_init_module+0x175/0x230    __x64_sys_finit_module+0x5d/0xb0    x64_sys_call+0x1c3/0x9e0    do_syscall_64+0x3d/0xc0    entry_SYSCALL_64_after_hwframe+0x4b/0x53    ......    \u0026lt;/TASK\u0026gt;   ---[ end trace 0000000000000000 ]---  The warning is triggered as follows:  1) syscall finit_module() handles the module insertion and it invokes kernel_read_file() to read the content of the module first.  2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and passes it to kernel_read(). kernel_read() constructs a kvec iter by using iov_iter_kvec() and passes it to fuse_file_read_iter().  3) virtio-fs disables the cache, so fuse_file_read_iter() invokes fuse_direct_io(). As for now, the maximal read size for kvec iter is only limited by fc-\u0026gt;max_read. For virtio-fs, max_read is UINT_MAX, so fuse_direct_io() doesn\u0026apos;t split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in out_args[0] of a fuse request and passes the fuse request to virtio_fs_wake_pending_and_unlock().  4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to queue the request. Because virtiofs need DMA-able address, so virtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in __alloc_pages():   if (WARN_ON_ONCE_GFP(order \u0026gt; MAX_PAGE_ORDER, gfp))   return NULL;  5) virtio_fs_enqueue_req() will retry the memory allocation in a kworker, but it won\u0026apos;t help, because kmalloc() will always return NULL due to the abnormal size and finit_module() will hang forever.  A feasible solution is to limit the value of max_read for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc-\u0026gt;max_write in kernel.  So instead of limiting both the values of max_read and max_write in kernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as true in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use pages instead of pointer to pass the KVEC_IO data.  After switching to pages for KVEC_IO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}_kernel_vmap_range() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuse_args_pages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fuse_get_user_pages() for write operations and the invalidation in fuse_release_user_pages() for read operations.  It may seem necessary to introduce another fie ---truncated---(CVE-2024-53219)\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:  RDMA/mlx5: Move events notifier registration to be after device registration  Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events.  Fix a race between the device deregistration and pkey change work by moving MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below.  BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkey_change_handler [mlx5_ib] RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 \u0026lt;4c\u0026gt; 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib] process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x380/0x380 kthread+0x149/0x170 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]---(CVE-2024-53224)\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:  ALSA: 6fire: Release resources at card release  The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort().  But at this moment, the card object might be still in use (as we\u0026apos;re calling snd_card_free_when_closed()).  For avoid potential UAFs, move the release of resources to the card\u0026apos;s private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback.(CVE-2024-53239)\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:  i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()  if (dev-\u0026gt;boardinfo \u0026amp;\u0026amp; dev-\u0026gt;boardinfo-\u0026gt;init_dyn_addr)                                       ^^^ here check \u0026quot;init_dyn_addr\u0026quot;  i3c_bus_set_addr_slot_status(\u0026amp;master-\u0026gt;bus, dev-\u0026gt;info.dyn_addr, ...)                    ^^^^        free \u0026quot;dyn_addr\u0026quot; Fix copy/paste error \u0026quot;dyn_addr\u0026quot; by replacing it with \u0026quot;init_dyn_addr\u0026quot;.(CVE-2024-56562)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ad7780: fix division by zero in ad7780_write_raw()  In the ad7780_write_raw() , val2 can be zero, which might lead to a division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw() is based on iio_info\u0026apos;s write_raw. While val is explicitly declared that can be zero (in read mode), val2 is not specified to be non-zero.(CVE-2024-56567)\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:  ovl: Filter invalid inodes with missing lookup function  Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack.(CVE-2024-56570)\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:  sched/deadline: Fix warning in migrate_enable for boosted tasks  When running the following command:  while true; do     stress-ng --cyclic 30 --timeout 30s --minimize --quiet done  a warning is eventually triggered:  WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794 setup_new_dl_entity+0x13e/0x180 ... Call Trace:  \u0026lt;TASK\u0026gt;  ? show_trace_log_lvl+0x1c4/0x2df  ? enqueue_dl_entity+0x631/0x6e0  ? setup_new_dl_entity+0x13e/0x180  ? __warn+0x7e/0xd0  ? report_bug+0x11a/0x1a0  ? handle_bug+0x3c/0x70  ? exc_invalid_op+0x14/0x70  ? asm_exc_invalid_op+0x16/0x20  enqueue_dl_entity+0x631/0x6e0  enqueue_task_dl+0x7d/0x120  __do_set_cpus_allowed+0xe3/0x280  __set_cpus_allowed_ptr_locked+0x140/0x1d0  __set_cpus_allowed_ptr+0x54/0xa0  migrate_enable+0x7e/0x150  rt_spin_unlock+0x1c/0x90  group_send_sig_info+0xf7/0x1a0  ? kill_pid_info+0x1f/0x1d0  kill_pid_info+0x78/0x1d0  kill_proc_info+0x5b/0x110  __x64_sys_kill+0x93/0xc0  do_syscall_64+0x5c/0xf0  entry_SYSCALL_64_after_hwframe+0x6e/0x76  RIP: 0033:0x7f0dab31f92b  This warning occurs because set_cpus_allowed dequeues and enqueues tasks with the ENQUEUE_RESTORE flag set. If the task is boosted, the warning is triggered. A boosted task already had its parameters set by rt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary, hence the WARN_ON call.  Check if we are requeueing a boosted task and avoid calling setup_new_dl_entity if that\u0026apos;s the case.(CVE-2024-56583)\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:  f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.  creating a large files during checkpoint disable until it runs out of space and then delete it, then remount to enable checkpoint again, and then unmount the filesystem triggers the f2fs_bug_on as below:  ------------[ cut here ]------------ kernel BUG at fs/f2fs/inode.c:896! CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360 Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:f2fs_evict_inode+0x58c/0x610 Call Trace:  __die_body+0x15/0x60  die+0x33/0x50  do_trap+0x10a/0x120  f2fs_evict_inode+0x58c/0x610  do_error_trap+0x60/0x80  f2fs_evict_inode+0x58c/0x610  exc_invalid_op+0x53/0x60  f2fs_evict_inode+0x58c/0x610  asm_exc_invalid_op+0x16/0x20  f2fs_evict_inode+0x58c/0x610  evict+0x101/0x260  dispose_list+0x30/0x50  evict_inodes+0x140/0x190  generic_shutdown_super+0x2f/0x150  kill_block_super+0x11/0x40  kill_f2fs_super+0x7d/0x140  deactivate_locked_super+0x2a/0x70  cleanup_mnt+0xb3/0x140  task_work_run+0x61/0x90  The root cause is: creating large files during disable checkpoint period results in not enough free segments, so when writing back root inode will failed in f2fs_enable_checkpoint. When umount the file system after enabling checkpoint, the root inode is dirty in f2fs_evict_inode function, which triggers BUG_ON. The steps to reproduce are as follows:  dd if=/dev/zero of=f2fs.img bs=1M count=55 mount f2fs.img f2fs_dir -o checkpoint=disable:10% dd if=/dev/zero of=big bs=1M count=50 sync rm big mount -o remount,checkpoint=enable f2fs_dir umount f2fs_dir  Let\u0026apos;s redirty inode when there is not free segments during checkpoint is disable.(CVE-2024-56586)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: set the right AMDGPU sg segment limitation  The driver needs to set the correct max_segment_size; otherwise debug_dma_map_sg() will complain about the over-mapping of the AMDGPU sg length as following:  WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370 [  364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd [  364.049532]  ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [  364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G           OE      6.10.0-custom #492 [  364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [  364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370 [  364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff \u0026lt;0f\u0026gt; 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05 [  364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286 [  364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027 [  364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680 [  364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930 [  364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000 [  364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800 [  364.049599] FS:  00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000 [  364.049601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0 [  364.049605] Call Trace: [  364.049607]  \u0026lt;TASK\u0026gt; [  364.049609]  ? show_regs+0x6d/0x80 [  364.049614]  ? __warn+0x8c/0x140 [  364.049618]  ? debug_dma_map_sg+0x2dc/0x370 [  364.049621]  ? report_bug+0x193/0x1a0 [  364.049627]  ? handle_bug+0x46/0x80 [  364.049631]  ? exc_invalid_op+0x1d/0x80 [  364.049635]  ? asm_exc_invalid_op+0x1f/0x30 [  364.049642]  ? debug_dma_map_sg+0x2dc/0x370 [  364.049647]  __dma_map_sg_attrs+0x90/0xe0 [  364.049651]  dma_map_sgtable+0x25/0x40 [  364.049654]  amdgpu_bo_move+0x59a/0x850 [amdgpu] [  364.049935]  ? srso_return_thunk+0x5/0x5f [  364.049939]  ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu] [  364.050095]  ttm_bo_handle_move_mem+0xc3/0x180 [ttm] [  364.050103]  ttm_bo_validate+0xc1/0x160 [ttm] [  364.050108]  ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu] [  364.050263]  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu] [  364.050473]  kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu] [  364.050680]  kfd_ioctl+0x3c2/0x530 [amdgpu] [  364.050866]  ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu] [  364.05105 ---truncated---(CVE-2024-56594)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: fix array-index-out-of-bounds in jfs_readdir  The stbl might contain some invalid values. Added a check to return error code in that case.(CVE-2024-56596)\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:  Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()  bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code.(CVE-2024-56605)\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:  nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()  Syzbot reported that when searching for records in a directory where the inode\u0026apos;s i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled.  This is because nilfs_last_byte(), which is called by nilfs_find_entry() and others to calculate the number of valid bytes of directory data in a page from i_size and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the i_size value is assigned.  This caused a large byte offset value due to underflow in the end address calculation in the calling nilfs_find_entry(), resulting in memory access that exceeds the folio/page size.  Fix this issue by changing the type of the local variable causing the bit loss from \u0026quot;unsigned int\u0026quot; to \u0026quot;u64\u0026quot;.  The return value of nilfs_last_byte() is also of type \u0026quot;unsigned int\u0026quot;, but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required.(CVE-2024-56619)\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:  blk-cgroup: Fix UAF in blkcg_unpin_online()  blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcg_parent(blkcg) but it was calling that after blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF:    ==================================================================   BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270   Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117    CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022   Workqueue: cgwb_release cgwb_release_workfn   Call Trace:    \u0026lt;TASK\u0026gt;    dump_stack_lvl+0x27/0x80    print_report+0x151/0x710    kasan_report+0xc0/0x100    blkcg_unpin_online+0x15a/0x270    cgwb_release_workfn+0x194/0x480    process_scheduled_works+0x71b/0xe20    worker_thread+0x82a/0xbd0    kthread+0x242/0x2c0    ret_from_fork+0x33/0x70    ret_from_fork_asm+0x1a/0x30    \u0026lt;/TASK\u0026gt;   ...   Freed by task 1944:    kasan_save_track+0x2b/0x70    kasan_save_free_info+0x3c/0x50    __kasan_slab_free+0x33/0x50    kfree+0x10c/0x330    css_free_rwork_fn+0xe6/0xb30    process_scheduled_works+0x71b/0xe20    worker_thread+0x82a/0xbd0    kthread+0x242/0x2c0    ret_from_fork+0x33/0x70    ret_from_fork_asm+0x1a/0x30  Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcg_unpin_online().  Fix it by reading the parent pointer before destroying the blkcg\u0026apos;s blkg\u0026apos;s.(CVE-2024-56672)\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:  ext4: fix race in buffer_head read fault injection  When I enabled ext4 debug for fault injection testing, I encountered the following warning:    EXT4-fs error (device sda): ext4_read_inode_bitmap:201: comm fsstress:          Cannot read inode bitmap - block_group = 8, inode_bitmap = 1051   WARNING: CPU: 0 PID: 511 at fs/buffer.c:1181 mark_buffer_dirty+0x1b3/0x1d0  The root cause of the issue lies in the improper implementation of ext4\u0026apos;s buffer_head read fault injection. The actual completion of buffer_head read and the buffer_head fault injection are not atomic, which can lead to the uptodate flag being cleared on normally used buffer_heads in race conditions.  [CPU0]           [CPU1]         [CPU2] ext4_read_inode_bitmap   ext4_read_bh()   \u0026lt;bh read complete\u0026gt;                  ext4_read_inode_bitmap                    if (buffer_uptodate(bh))                      return bh                                jbd2_journal_commit_transaction                                  __jbd2_journal_refile_buffer                                    __jbd2_journal_unfile_buffer                                      __jbd2_journal_temp_unlink_buffer   ext4_simulate_fail_bh()     clear_buffer_uptodate                                       mark_buffer_dirty                                         \u0026lt;report warning\u0026gt;                                         WARN_ON_ONCE(!buffer_uptodate(bh))  The best approach would be to perform fault injection in the IO completion callback function, rather than after IO completion. However, the IO completion callback function cannot get the fault injection code in sb.  Fix it by passing the result of fault injection into the bh read function, we simulate faults within the bh read function itself. This requires adding an extra parameter to the bh read functions that need fault injection.(CVE-2024-56686)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device  While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ).  Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56691)\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:  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:  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:  RDMA/hns: Fix cpu stuck caused by printings during reset  During reset, cmd to destroy resources such as qp, cq, and mr may fail, and error logs will be printed. When a large number of resources are destroyed, there will be lots of printings, and it may lead to a cpu stuck.  Delete some unnecessary printings and replace other printing functions in these paths with the ratelimited version.(CVE-2024-56722)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  rtc: check if __rtc_read_time was successful in rtc_timer_do_work()  If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware.  When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc-\u0026gt;timerqueue, they will continually expire, may causing kernel softlockup.(CVE-2024-56739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()  Hook \u0026quot;qedi_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-56747)\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:  nvme-pci: fix freeing of the HMB descriptor table  The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent.  In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page.(CVE-2024-56756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing: Prevent bad count for tracing_cpumask_write  If a large count is provided, it will trigger a warning in bitmap_parse_user. Also check zero for it.(CVE-2024-56763)",
  "id": "OESA-2025-1035",
  "modified": "2026-08-06T11:08:07Z",
  "published": "2025-01-10T11:08:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49002"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49034"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47730"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49856"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49907"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50001"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50188"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50233"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50264"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50287"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53147"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53155"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53158"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53161"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53165"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53171"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53185"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53187"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53194"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53197"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53219"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53221"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53224"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53227"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53239"
    },
    {
      "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-56562"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56567"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56569"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56570"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56581"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56583"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56584"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56586"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56594"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56596"
    },
    {
      "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-56605"
    },
    {
      "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-56619"
    },
    {
      "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-56672"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56686"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56691"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56692"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56700"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56709"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56722"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56748"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56763"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-49002",
    "CVE-2022-49034",
    "CVE-2022-49035",
    "CVE-2024-47730",
    "CVE-2024-49856",
    "CVE-2024-49907",
    "CVE-2024-50001",
    "CVE-2024-50188",
    "CVE-2024-50233",
    "CVE-2024-50264",
    "CVE-2024-50287",
    "CVE-2024-53147",
    "CVE-2024-53155",
    "CVE-2024-53158",
    "CVE-2024-53161",
    "CVE-2024-53165",
    "CVE-2024-53171",
    "CVE-2024-53185",
    "CVE-2024-53187",
    "CVE-2024-53194",
    "CVE-2024-53197",
    "CVE-2024-53219",
    "CVE-2024-53221",
    "CVE-2024-53224",
    "CVE-2024-53227",
    "CVE-2024-53239",
    "CVE-2024-56538",
    "CVE-2024-56548",
    "CVE-2024-56562",
    "CVE-2024-56567",
    "CVE-2024-56569",
    "CVE-2024-56570",
    "CVE-2024-56581",
    "CVE-2024-56583",
    "CVE-2024-56584",
    "CVE-2024-56586",
    "CVE-2024-56594",
    "CVE-2024-56596",
    "CVE-2024-56598",
    "CVE-2024-56604",
    "CVE-2024-56605",
    "CVE-2024-56608",
    "CVE-2024-56615",
    "CVE-2024-56619",
    "CVE-2024-56627",
    "CVE-2024-56629",
    "CVE-2024-56630",
    "CVE-2024-56672",
    "CVE-2024-56681",
    "CVE-2024-56686",
    "CVE-2024-56691",
    "CVE-2024-56692",
    "CVE-2024-56700",
    "CVE-2024-56709",
    "CVE-2024-56722",
    "CVE-2024-56739",
    "CVE-2024-56747",
    "CVE-2024-56748",
    "CVE-2024-56756",
    "CVE-2024-56763"
  ]
}

OESA-2025-1036 (CVE-2022-49034)

Vulnerability from osv_openeuler – Published: 2025-01-10 11:08 – Updated: 2026-08-06 11:08 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In 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] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---(CVE-2022-49034)

In the Linux kernel, the following vulnerability has been resolved:

firmware: qcom: scm: Mark get_wq_ctx() as atomic call

Currently get_wq_ctx() is wrongly configured as a standard call. When two SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to resume the corresponding sleeping thread. But if get_wq_ctx() is interrupted, goes to sleep and another SMC call is waiting to be allocated a waitq context, it leads to a deadlock.

To avoid this get_wq_ctx() must be an atomic call and can't be a standard SMC call. Hence mark get_wq_ctx() as a fast call.(CVE-2024-46692)

In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: Prevent unmapping active read buffers

The kms paths keep a persistent map active to read and compare the cursor buffer. These maps can race with each other in simple scenario where: a) buffer "a" mapped for update b) buffer "a" mapped for compare c) do the compare d) unmap "a" for compare e) update the cursor f) unmap "a" for update At step "e" the buffer has been unmapped and the read contents is bogus.

Prevent unmapping of active read buffers by simply keeping a count of how many paths have currently active maps and unmap only when the count reaches 0.(CVE-2024-46710)

In the Linux kernel, the following vulnerability has been resolved:

xen: privcmd: Fix possible access to a freed kirqfd instance

Nothing prevents simultaneous ioctl calls to privcmd_irqfd_assign() and privcmd_irqfd_deassign(). If that happens, it is possible that a kirqfd created and added to the irqfds_list by privcmd_irqfd_assign() may get removed by another thread executing privcmd_irqfd_deassign(), while the former is still using it after dropping the locks.

This can lead to a situation where an already freed kirqfd instance may be accessed and cause kernel oops.

Use SRCU locking to prevent the same, as is done for the KVM implementation for irqfds.(CVE-2024-46762)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.(CVE-2024-49906)

In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.(CVE-2024-50069)

In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)(CVE-2024-50075)

In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.(CVE-2024-50185)

In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.(CVE-2024-50233)

In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.(CVE-2024-53081)

In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: "Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, please set promiscuous on manually for VF XX". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.(CVE-2024-53088)

In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.(CVE-2024-53103)

In 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't intended to be advertised on Zen4 client so clear the capability.(CVE-2024-53114)

In 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)

In the Linux kernel, the following vulnerability has been resolved: Revert "mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K" The commit 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K") 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 - "swiotlb buffer is full" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.(CVE-2024-53127)

In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"(CVE-2024-53134)

In the Linux kernel, the following vulnerability has been resolved: mm: revert "mm: shmem: fix data-race in shmem_getattr()" Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") as suggested by Chuck [1]. It is causing deadlocks when accessing tmpfs over NFS. As Hugh commented, "added just to silence a syzbot sanitizer splat: added where there has never been any practical problem".(CVE-2024-53136)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent a potential integer overflow If the tag length is >= U32_MAX - 3 then the "length + 4" 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)

In 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->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)

In the Linux kernel, the following vulnerability has been resolved: svcrdma: Address an integer overflow Dan Carpenter reports: > Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data > structure") from Jun 22, 2020 (linux-next), leads to the following > Smatch static checker warning: > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk() > warn: potential user controlled sizeof overflow 'segcount * 4 * 4' > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c > 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt rctxt) > 489 { > 490 u32 segcount; > 491 __be32 p; > 492 > 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount)) > ^^^^^^^^ > > 494 return false; > 495 > 496 / A bogus segcount causes this buffer overflow check to fail. / > 497 p = xdr_inline_decode(&rctxt->rc_stream, > --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p)); > > > segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will > have an integer overflow and some those values will be accepted by > xdr_inline_decode().(CVE-2024-53151)

In 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)

In the Linux kernel, the following vulnerability has been resolved: EDAC/bluefield: Fix potential integer overflow The 64-bit argument for the "get DIMM info" 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)

In 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 "num_objs" is the ARRAY_SIZE() of fw_objs[]. The > needs to be >= to prevent an out of bounds access.(CVE-2024-53163)

In 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's only add it to the list after everything has succeeded.(CVE-2024-53165)

In 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 ("block: keep q_usage_counter in atomic mode after del_gendisk"), hence for disk like scsi, following blk_mq_destroy_queue() will not clear flush rq from tags->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 _kasankmalloc 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 _kasanslab_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)

In 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)

In 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->r_count to reach zero: wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0); - Meanwhile, handle_ksmbd_work() decrements conn->r_count using atomic_dec_return(&conn->r_count), and if it reaches zero, calls ksmbd_conn_free(), which frees conn. - However, after handle_ksmbd_work() decrements conn->r_count, it may still access conn->r_count_q in the following line: waitqueue_active(&conn->r_count_q) or wake_up(&conn->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's support for SMB requests.(CVE-2024-53186)

In 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->config. This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration.(CVE-2024-53197)

In 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)

In 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)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null-ptr-deref in f2fs_submit_page_bio() There'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: <TASK> 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 "f2fs_fs_type". To address above issue just register "f2fs_fs_type" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized.(CVE-2024-53221)

In 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: <TASK> 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 </TASK> 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); --> Trigger double release Don't call bfad_im_module_exit() if bfad_im_module_init() failed.(CVE-2024-53227)

In 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->cpus cpu mask and it will cause null pointer dereference, so check NULL for cppc_get_cpu_cost().(CVE-2024-53230)

In 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's internals.(CVE-2024-56538)

In the Linux kernel, the following vulnerability has been resolved: hfsplus: don'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] <TASK> [ 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 <48> 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)

In 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 "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filter The current mod command causes a null pointer dereference. While commit 0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter") has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash.(CVE-2024-56569)

In 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)

In 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)

In 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 'ref') into the respective block entry's rbtree (local variable 'be'), 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'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'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)

In 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(&tctx->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 ->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)

In 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)

In 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)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bounds access in 'dcn21_link_encoder_create' 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'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 'dcn10_link_enc_hpd_registers [5]' [ 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] <TASK> [ 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] ? __pfxdriverattach+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 <48> 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] </TASK> [ 65.923927] ---[ end trace ]---(CVE-2024-56608)

In 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 <48> 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] <TASK> [ 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] </TASK>(CVE-2024-56615)

In 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)

In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix out_fput in iommufd_fault_alloc() As fput() calls the file->f_op->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)

In 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 'vfs objects = streams_xattr parameter' in ksmbd.conf.(CVE-2024-56627)

In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix when get product name maybe null pointer Due to incorrect dev->product reporting by certain devices, null pointer dereferences occur when dev->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)

In 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 ("ocfs2: Handle error from dquot_initialize()") forgot to call iput() when new_inode() succeeded and dquot_initialize() failed.(CVE-2024-56630)

In 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 -> chid creates inherited event the new child event shares the parent's bpf program and tp_event (hence prog_array) which is global for tracepoint - exit both process and its child -> release both events - first perf_event_detach_bpf_prog call will release tp_event->prog_array and second perf_event_detach_bpf_prog will crash, because tp_event->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)

In 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)

In 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)

In 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)

In 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's add sanity check on nat blkaddr in truncate_node().(CVE-2024-56692)

In 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: <TASK> 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'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->bd_disk->fops->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->bd_disk->fops->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)

In 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->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->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)

In 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'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't do this when ref_obj_id > 0, as in that case this is an acquired object and doesn'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'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)

In 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->pvt_info will point to &igen6_pvt->imc[mc] During rmmod: 1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info) 2. In igen6_remove(), it will kfree(igen6_pvt); Fix this issue by setting mci->pvt_info to NULL to avoid the double kfree.(CVE-2024-56708)

In 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's the final task_work run or the fallback path. In this case, task work will find ->io_wq being already killed and null'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 ->iowq check would race.(CVE-2024-56709)

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix cpu stuck caused by printings during reset During reset, cmd to destroy resources such as qp, cq, and mr may fail, and error logs will be printed. When a large number of resources are destroyed, there will be lots of printings, and it may lead to a cpu stuck. Delete some unnecessary printings and replace other printing functions in these paths with the ratelimited version.(CVE-2024-56722)

In 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 "kunit_try_catch", pid 225, jiffies 4294894407 hex dump (first 8 bytes): 74 65 73 74 69 6e 67 00 testing. backtrace (crc 5eab668b): [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 [<000000006e6c7776>] __kmalloc_node_track_caller_noprof+0x300/0x3e0 [<000000006870467c>] kmemdup_noprof+0x34/0x60 [<000000001176bb03>] aa_unpack_strdup+0xd0/0x18c [<000000008ecde918>] policy_unpack_test_unpack_strdup_with_null_name+0xf8/0x3ec [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] ret_from_fork+0x10/0x20 unreferenced object 0xffffff80c2a29090 (size 8): comm "kunit_try_catch", pid 227, jiffies 4294894409 hex dump (first 8 bytes): 74 65 73 74 69 6e 67 00 testing. backtrace (crc 5eab668b): [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 [<000000006e6c7776>] __kmalloc_node_track_caller_noprof+0x300/0x3e0 [<000000006870467c>] kmemdup_noprof+0x34/0x60 [<000000001176bb03>] aa_unpack_strdup+0xd0/0x18c [<0000000046a45c1a>] policy_unpack_test_unpack_strdup_with_name+0xd0/0x3c4 [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] ret_from_fork+0x10/0x20(CVE-2024-56741)

In 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 (&sbi->sb_lock){++++}-{3:3}, at: f2fs_down_write fs/f2fs/f2fs.h:2199 [inline] ffff888011824088 (&sbi->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: -> #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 -> #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)

In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb() Hook "qed_ops->common->sb_init = qed_sb_init" 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)

In 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->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 '&gr->fecs.mutex'.(CVE-2024-56752)

Severity

7.8 (High)


                    
                      CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-49034	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46692	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46710	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-46762	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-49906	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50069	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50075	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50185	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-50233	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53081	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53088	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53103	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53114	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53126	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53127	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53134	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53136	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53146	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53147	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53151	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53154	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53161	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53163	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53165	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53170	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53173	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53186	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53197	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53202	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53217	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53221	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53227	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-53230	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56538	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56548	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56569	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56575	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56578	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56581	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56584	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56598	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56604	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56608	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56615	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56620	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56624	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56627	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56629	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56630	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56665	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56675	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56681	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56683	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56692	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56693	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56700	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56702	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56708	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56709	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56722	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56741	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56744	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56748	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-56752	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "kernel-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "perf-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-73.0.0.65.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-73.0.0.65.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-73.0.0.65.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "kernel-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "perf-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-73.0.0.65.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-73.0.0.65.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-73.0.0.65.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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:\r\n\r\nfirmware: qcom: scm: Mark get_wq_ctx() as atomic call\r\n\r\nCurrently get_wq_ctx() is wrongly configured as a standard call. When two\nSMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to\nresume the corresponding sleeping thread. But if get_wq_ctx() is\ninterrupted, goes to sleep and another SMC call is waiting to be allocated\na waitq context, it leads to a deadlock.\r\n\r\nTo avoid this get_wq_ctx() must be an atomic call and can\u0026apos;t be a standard\nSMC call. Hence mark get_wq_ctx() as a fast call.(CVE-2024-46692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Prevent unmapping active read buffers\r\n\r\nThe kms paths keep a persistent map active to read and compare the cursor\nbuffer. These maps can race with each other in simple scenario where:\na) buffer \u0026quot;a\u0026quot; mapped for update\nb) buffer \u0026quot;a\u0026quot; mapped for compare\nc) do the compare\nd) unmap \u0026quot;a\u0026quot; for compare\ne) update the cursor\nf) unmap \u0026quot;a\u0026quot; for update\nAt step \u0026quot;e\u0026quot; the buffer has been unmapped and the read contents is bogus.\r\n\r\nPrevent unmapping of active read buffers by simply keeping a count of\nhow many paths have currently active maps and unmap only when the count\nreaches 0.(CVE-2024-46710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxen: privcmd: Fix possible access to a freed kirqfd instance\r\n\r\nNothing prevents simultaneous ioctl calls to privcmd_irqfd_assign() and\nprivcmd_irqfd_deassign(). If that happens, it is possible that a kirqfd\ncreated and added to the irqfds_list by privcmd_irqfd_assign() may get\nremoved by another thread executing privcmd_irqfd_deassign(), while the\nformer is still using it after dropping the locks.\r\n\r\nThis can lead to a situation where an already freed kirqfd instance may\nbe accessed and cause kernel oops.\r\n\r\nUse SRCU locking to prevent the same, as is done for the KVM\nimplementation for irqfds.(CVE-2024-46762)\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:  pinctrl: apple: check devm_kasprintf() returned value  devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value.  Found by code review.(CVE-2024-50069)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  xhci: tegra: fix checked USB2 port number  If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller.  Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access.  [  116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [  117.213640] Call trace: [  117.216783]  tegra_xusb_enter_elpg+0x23c/0x658 [  117.222021]  tegra_xusb_runtime_suspend+0x40/0x68 [  117.227260]  pm_generic_runtime_suspend+0x30/0x50 [  117.232847]  __rpm_callback+0x84/0x3c0 [  117.237038]  rpm_suspend+0x2dc/0x740 [  117.241229] pm_runtime_work+0xa0/0xb8 [  117.245769]  process_scheduled_works+0x24c/0x478 [  117.251007]  worker_thread+0x23c/0x328 [  117.255547]  kthread+0x104/0x1b0 [  117.259389]  ret_from_fork+0x10/0x20 [  117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)(CVE-2024-50075)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mptcp: handle consistently DSS corruption  Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.(CVE-2024-50185)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()  In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout \u0026gt; (clk_get_rate(st-\u0026gt;mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.(CVE-2024-50233)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: ar0521: don\u0026apos;t overflow when checking PLL values  The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow.  Fix it ensuring that both sides of the expression are u64.(CVE-2024-53081)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  i40e: fix race condition by adding filter\u0026apos;s intermediate sync state  Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN.  1. Thread T0 allocates a filter in i40e_add_filter() within         i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within         i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which         refers to the already freed filter memory, causing corruption.  Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change         MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \u0026quot;Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,  please set promiscuous on manually for VF XX\u0026quot;.  Exact code for stable reproduction Intel can\u0026apos;t open-source now.  The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.(CVE-2024-53088)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  hv_sock: Initializing vsk-\u0026gt;trans to NULL to prevent a dangling pointer  When hvs is released, there is a possibility that vsk-\u0026gt;trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk-\u0026gt;trans to NULL.(CVE-2024-53103)\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:  RDMA/hns: Fix cpu stuck caused by printings during reset  During reset, cmd to destroy resources such as qp, cq, and mr may fail, and error logs will be printed. When a large number of resources are destroyed, there will be lots of printings, and it may lead to a cpu stuck.  Delete some unnecessary printings and replace other printing functions in these paths with the ratelimited version.(CVE-2024-56722)\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)",
  "id": "OESA-2025-1036",
  "modified": "2026-08-06T11:08:07Z",
  "published": "2025-01-10T11:08:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1036"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49034"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46692"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46710"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46762"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49906"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50069"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50075"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50185"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50233"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53081"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53088"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53103"
    },
    {
      "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-56722"
    },
    {
      "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-49034",
    "CVE-2024-46692",
    "CVE-2024-46710",
    "CVE-2024-46762",
    "CVE-2024-49906",
    "CVE-2024-50069",
    "CVE-2024-50075",
    "CVE-2024-50185",
    "CVE-2024-50233",
    "CVE-2024-53081",
    "CVE-2024-53088",
    "CVE-2024-53103",
    "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-56722",
    "CVE-2024-56741",
    "CVE-2024-56744",
    "CVE-2024-56748",
    "CVE-2024-56752"
  ]
}

OESA-2025-1037 (CVE-2022-49034)