Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49350 State: PUBLISHED Published: 2025-02-26T02:11:03.514Z Last Updated: 2025-05-04T08:35:51.230Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it:
I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, drivers/net/phy/phy_device.c is never compiled as modular. (CONFIG_PHYLIB is boolean) References: - https://git.kernel.org/stable/c/ab64ec2c75683f30ccde9eaaf0761002f901aa12 - https://git.kernel.org/stable/c/5534bcd7c40299862237c4a8fd9c5031b3db1538 - https://git.kernel.org/stable/c/6a90a44d53428a3bf01bd80df9ba78b19959270c - https://git.kernel.org/stable/c/7759c3222815b945a94b212bc0c6cdec475cfec2 - https://git.kernel.org/stable/c/59fa94cddf9eef8d8dae587373eed8b8f4eb11d7
le/c/7759c3222815b945a94b212bc0c6cdec475cfec2 - https://git.kernel.org/stable/c/59fa94cddf9eef8d8dae587373eed8b8f4eb11d7 - https://git.kernel.org/stable/c/f5c68137f1191ba3fcf6260ec71b30be2e2bf4c3 - https://git.kernel.org/stable/c/f2f0f8c18b60ca64ff50892ed899cf1c77864755 - https://git.kernel.org/stable/c/35b42dce619701f1300fb8498dae82c9bb1f0263
CVE ID: CVE-2022-49351 State: PUBLISHED Published: 2025-02-26T02:11:04.014Z Last Updated: 2025-10-01T19:46:54.459Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: altera: Fix refcount leak in altera_tse_mdio_create Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid refcount leak. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a013fa884d8738ad8455aa1a843b8c9d80c6c833
Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a013fa884d8738ad8455aa1a843b8c9d80c6c833 - https://git.kernel.org/stable/c/1fd12298a0e0ca23478c715e672ee64c85670584 - https://git.kernel.org/stable/c/5cd0e22fa11f4a21a8c09cc258f20b1474c95801 - https://git.kernel.org/stable/c/8174acbef87b8dd8bf3731eba2a5af1ac857e239 - https://git.kernel.org/stable/c/96bf5ed057df2d157274d4e2079002f9a9404bb8 - https://git.kernel.org/stable/c/e31d9ba169860687dba19bdc8fccbfd34077f655 - https://git.kernel.org/stable/c/803b217f1fb49a2dbb2123acdb45111b9c48b8be - https://git.kernel.org/stable/c/4f850fe0a32c3f1e19b76996a3b1ca32637a14de - https://git.kernel.org/stable/c/11ec18b1d8d92b9df307d
git.kernel.org/stable/c/4f850fe0a32c3f1e19b76996a3b1ca32637a14de - https://git.kernel.org/stable/c/11ec18b1d8d92b9df307d31950dcba0b3dd7283c
CVE ID: CVE-2022-49352 State: PUBLISHED Published: 2025-02-26T02:11:04.496Z Last Updated: 2025-06-19T12:56:19.413Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in ext4_handle_inode_extension We got issue as follows: EXT4-fs error (device loop0) in ext4_reserve_inode_write:5741: Out of memory EXT4-fs error (device loop0): ext4_setattr:5462: inode #13: comm syz-executor.0: mark_inode_dirty error EXT4-fs error (device loop0) in ext4_setattr:5519: Out of memory EXT4-fs error (device loop0): ext4_ind_map_blocks:595: inode #13: comm syz-executor.0: Can't allocate blocks for non-extent mapped inodes with bigalloc -
4_ind_map_blocks:595: inode #13: comm syz-executor.0: Can't allocate blocks for non-extent mapped inodes with bigalloc ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4361 at fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220 Modules linked in: CPU: 1 PID: 4361 Comm: syz-executor.0 Not tainted 5.10.0+ #1 RIP: 0010:ext4_file_write_iter+0x11c9/0x1220 RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282 RAX: ffffffff815a3379 RBX: 0000000000000000 RCX: 000000003b000000 RDX: ffff924d81601000 RSI: 00000000000009cc RDI: 00000000000009cd RBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 000000000000000a R13: 0000000000000001 R14: f
c6b R09: 0000902e0e52a96f R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 000000000000000a R13: 0000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b FS: 00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffff600400 CR3: 000000012db88001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: do_iter_readv_writev+0x2e5/0x360 do_iter_write+0x112/0x4c0 do_pwritev+0x1e5/0x390 __x64_sys_pwritev2+0x7e/0xa0 do_syscall_64+0x37/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follo
_sys_pwritev2+0x7e/0xa0 do_syscall_64+0x37/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: Assume inode.i_size=4096 EXT4_I(inode)->i_disksize=4096 step 1: set inode->i_isize = 8192 ext4_setattr if (attr->ia_size != inode->i_size) EXT4_I(inode)->i_disksize = attr->ia_size; rc = ext4_mark_inode_dirty ext4_reserve_inode_write ext4_get_inode_loc __ext4_get_inode_loc sb_getblk --> return -ENOMEM ... if (!error) ->will not update i_size i_size_write(inode, attr->ia_size); Now: inode.i_size=4096 EXT4_I(inode)->i_disksize=8192 step 2: Direct write 4096 bytes ext4_file_write_iter ext4_dio_write_iter iomap_dio_rw ->return error if (extend) ext4_handle_inode_extension W
096 bytes ext4_file_write_iter ext4_dio_write_iter iomap_dio_rw ->return error if (extend) ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize); ->Then trigger warning. To solve above issue, if mark inode dirty failed in ext4_setattr just set 'EXT4_I(inode)->i_disksize' with old value. References: - https://git.kernel.org/stable/c/adf490083ca52ebfb0b2fe64ff1ead00c0452dd7 - https://git.kernel.org/stable/c/b81d2ff6885e38fc745eeaf9565775055778fc0b - https://git.kernel.org/stable/c/e383c2aa5f02ab571530dc5c5696479672478c25 - https://git.kernel.org/stable/c/1bcce88da60eccc946c0f4ed942b0f08cd565778 - https://git.kernel.org/stable/c/f4534c9fc94d22383f187b9409abb3f
.org/stable/c/1bcce88da60eccc946c0f4ed942b0f08cd565778 - https://git.kernel.org/stable/c/f4534c9fc94d22383f187b9409abb3f9df2e3db3
CVE ID: CVE-2022-49353 State: PUBLISHED Published: 2025-02-26T02:11:04.982Z Last Updated: 2025-10-01T19:46:54.302Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/papr_scm: don't requests stats with '0' sized stats buffer Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being reported with vPMEM when papr_scm probe is being called. The panic is of the form below and is observed only with following option disabled(profile) for the said LPAR 'Enable Performance Information Collection' in the HMC: Kernel attempted to write user page (1c) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference
n' in the HMC: Kernel attempted to write user page (1c) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on write at 0x0000001c Faulting instruction address: 0xc008000001b90844 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c008000001b90844] drc_pmem_query_stats+0x5c/0x270 [papr_scm] LR [c008000001b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm] Call Trace: 0xc00000000941bca0 (unreliable) papr_scm_probe+0x2ac/0x6ec [papr_scm] platform_probe+0x98/0x150 really_probe+0xfc/0x510 __driver_probe_device+0x17c/0x230 <snip> ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception On investigation looks like this panic was caused due to a 'stat_buffer' o
- Kernel panic - not syncing: Fatal exception On investigation looks like this panic was caused due to a 'stat_buffer' of size==0 being provided to drc_pmem_query_stats() to fetch all performance stats-ids of an NVDIMM. However drc_pmem_query_stats() shouldn't have been called since the vPMEM NVDIMM doesn't support and performance stat-id's. This was caused due to missing check for 'p->stat_buffer_len' at the beginning of papr_scm_pmu_check_events() which indicates that the NVDIMM doesn't support performance-stats. Fix this by introducing the check for 'p->stat_buffer_len' at the beginning of papr_scm_pmu_check_events(). [1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@li
at the beginning of papr_scm_pmu_check_events(). [1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e1295aab2ebcda1c1a9ed342baedc080e5c393e5 - https://git.kernel.org/stable/c/07bf9431b1590d1cd7a8d62075d0b50b073f0495
CVE ID: CVE-2022-49354 State: PUBLISHED Published: 2025-02-26T02:11:05.466Z Last Updated: 2025-10-01T19:46:54.141Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() to avoid refcount leak. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7bd85c5ba1687daf54e3b6907673c3604b1e75cf - https://git.kernel.org/stable/c/a4d3e5f1d7d4f8b5e3834fec0f057a762c55806b - https://git.kernel.org/stable/c/8d8ad067b90f2
https://git.kernel.org/stable/c/a4d3e5f1d7d4f8b5e3834fec0f057a762c55806b - https://git.kernel.org/stable/c/8d8ad067b90f231b8fdb14acee673ca4012f6045 - https://git.kernel.org/stable/c/d5a1e7f33c88780b279835d63665d7e38ccb671f - https://git.kernel.org/stable/c/19cb3ece14547cb1ca2021798aaf49a3f82643d1 - https://git.kernel.org/stable/c/888312dc297a8a103f6371ef668c7e04f57a7679 - https://git.kernel.org/stable/c/c9782e1b21bee4b783a64b2a91e7e71406c21a21 - https://git.kernel.org/stable/c/fb2cb409b504bb3a69e65a17f3120328c8e50219 - https://git.kernel.org/stable/c/10d6bdf532902be1d8aa5900b3c03c5671612aa2
CVE ID: CVE-2022-49355 State: REJECTED Published: 2025-02-26T02:11:05.953Z Last Updated: 2025-02-26T11:29:30.958Z Description: No description available.
CVE ID: CVE-2022-49356 State: PUBLISHED Published: 2025-02-26T02:11:06.430Z Last Updated: 2025-05-04T08:35:56.828Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Trap RDMA segment overflows Prevent svc_rdma_build_writes() from walking off the end of a Write chunk's segment array. Caught with KASAN. The test that this fix replaces is invalid, and might have been left over from an earlier prototype of the PCL work. References: - https://git.kernel.org/stable/c/ea26bf5eca1459b5a7824997d7823409ce38214e - https://git.kernel.org/stable/c/812c13521d4a72469c78ce06d8cdc8dc5b5557b5 - https://git.kernel.org/stable/c/659f7568e09593
ttps://git.kernel.org/stable/c/812c13521d4a72469c78ce06d8cdc8dc5b5557b5 - https://git.kernel.org/stable/c/659f7568e09593945c221bf20217a82ebdfe1328 - https://git.kernel.org/stable/c/f012e95b377c73c0283f009823c633104dedb337
CVE ID: CVE-2022-49357 State: PUBLISHED Published: 2025-02-26T02:11:06.931Z Last Updated: 2025-05-04T08:35:58.200Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: efi: Do not import certificates from UEFI Secure Boot for T2 Macs On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs: [Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x5
0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) Call Trace: <TASK> page_fault_oops+0x4f/0x2c0 ? search_bpf_extables+0x6b/0x80 ? search_module_extables+0x50/0x80 ? search_exception_tables+0x5b/0x60 kernelmode_fixup_or_oops+0x9e/0x110 __bad_area_nosemaphore+0x155/0x190 bad_area_nosemaphore+0x16/0x20 do_kern_addr_fault+0x8c/0xa0 exc_page_fault+0xd8/0x180 asm_exc_page_fault+0x1e/0x30 (Removed some logs from here) ? __efi_call+0x28/0x30 ? switch_mm+0x20/0x30 ? efi_call_rts+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0
s+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0x3f0 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22/0x30 </TASK> ---[ end trace 1f82023595a5927f ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000 So we avoid reading these UEFI variables and thus prevent the crash. Re
kx list integrity: Couldn't get size: 0x80000000 So we avoid reading these UEFI variables and thus prevent the crash. References: - https://git.kernel.org/stable/c/b1cda6dd2c44771f042d65f0d17bec322ef99a0a - https://git.kernel.org/stable/c/c072cab98bac11f6ef9db640fb51834d9552e2e6 - https://git.kernel.org/stable/c/65237307f88f5200782ae7f243bdd385e37cde5d - https://git.kernel.org/stable/c/b34786b25d75f9c119696e6bdf3827f54ae3601b - https://git.kernel.org/stable/c/1f7264f0510f519b4e4f575a8f0579ea65e7592e - https://git.kernel.org/stable/c/155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb
CVE ID: CVE-2022-49358 State: PUBLISHED Published: 2025-02-26T02:11:07.432Z Last Updated: 2025-10-01T19:46:54.001Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: memleak flow rule from commit path Abort path release flow rule object, however, commit path does not. Update code to destroy these objects before releasing the transaction. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/5b8d63489c3b701eb2a76f848ec94d8cbc9373b9 - https://git.kernel.org/stable/c/330c0c6cd2150a2d7f47af16aa590078b0d2f736 - https://git.kernel.org/stable/c/e33d9bd563e71f6c6528b96008d655
l.org/stable/c/330c0c6cd2150a2d7f47af16aa590078b0d2f736 - https://git.kernel.org/stable/c/e33d9bd563e71f6c6528b96008d65524a459c4dc - https://git.kernel.org/stable/c/80de9ea1f5b808a6601e91111fae601df2b26369 - https://git.kernel.org/stable/c/ab9f34a30c23f656e76f4c5b83125a4e7b53c86e - https://git.kernel.org/stable/c/9dd732e0bdf538b1b76dc7c157e2b5e560ff30d3
CVE ID: CVE-2022-49359 State: PUBLISHED Published: 2025-02-26T02:11:07.930Z Last Updated: 2025-05-04T12:44:30.679Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Job should reference MMU not file_priv For a while now it's been allowed for a MMU context to outlive it's corresponding panfrost_priv, however the job structure still references panfrost_priv to get hold of the MMU context. If panfrost_priv has been freed this is a use-after-free which I've been able to trigger resulting in a splat. To fix this, drop the reference to panfrost_priv in the job structure and add a direct reference to the MMU structure which
fix this, drop the reference to panfrost_priv in the job structure and add a direct reference to the MMU structure which is what's actually needed. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8c8e8cc91a6ffc79865108279a74fd57d9070a17 - https://git.kernel.org/stable/c/472dd7ea5e19a1aeabf1711ddc756777e05ee7c2 - https://git.kernel.org/stable/c/6e516faf04317db2c46cbec4e3b78b4653a5b109
CVE ID: CVE-2022-49360 State: PUBLISHED Published: 2025-02-26T02:11:08.402Z Last Updated: 2025-07-11T17:19:15.783Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on total_data_blocks As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215916 The kernel message is shown below: kernel BUG at fs/f2fs/segment.c:2560! Call Trace: allocate_segment_by_default+0x228/0x440 f2fs_allocate_data_block+0x13d1/0x31f0 do_write_page+0x18d/0x710 f2fs_outplace_write_data+0x151/0x250 f2fs_do_write_data_page+0xef9/0x1980 move_data_page+0x6af/0xbc0 do_garbage_collect+0x312f/0x46f0 f2fs_gc+0x6b0/0
1/0x250 f2fs_do_write_data_page+0xef9/0x1980 move_data_page+0x6af/0xbc0 do_garbage_collect+0x312f/0x46f0 f2fs_gc+0x6b0/0x3bc0 f2fs_balance_fs+0x921/0x2260 f2fs_write_single_data_page+0x16be/0x2370 f2fs_write_cache_pages+0x428/0xd00 f2fs_write_data_pages+0x96e/0xd50 do_writepages+0x168/0x550 __writeback_single_inode+0x9f/0x870 writeback_sb_inodes+0x47d/0xb20 __writeback_inodes_wb+0xb2/0x200 wb_writeback+0x4bd/0x660 wb_workfn+0x5f3/0xab0 process_one_work+0x79f/0x13e0 worker_thread+0x89/0xf60 kthread+0x26a/0x300 ret_from_fork+0x22/0x30 RIP: 0010:new_curseg+0xe8d/0x15f0 The root cause is: ckpt.valid_block_count is inconsistent with SIT table, stat info indicates filesystem has free blocks, but S
t cause is: ckpt.valid_block_count is inconsistent with SIT table, stat info indicates filesystem has free blocks, but SIT table indicates filesystem has no free segment. So that during garbage colloection, it triggers panic when LFS allocator fails to find free segment. This patch tries to fix this issue by checking consistency in between ckpt.valid_block_count and block accounted from SIT. References: - https://git.kernel.org/stable/c/ef221b738b26d8c9f7e7967f4586db2dd3bd5288 - https://git.kernel.org/stable/c/c9e4cd5b0ccd7168801d6a811919171b185c5cf8 - https://git.kernel.org/stable/c/071b1269a3b3ad9cec16ed76a48015bfffd9aee8 - https://git.kernel.org/stable/c/cc8c9df19971e59ebbe669ce710080e347
g/stable/c/071b1269a3b3ad9cec16ed76a48015bfffd9aee8 - https://git.kernel.org/stable/c/cc8c9df19971e59ebbe669ce710080e347dfec32 - https://git.kernel.org/stable/c/6b8beca0edd32075a769bfe4178ca00c0dcd22a9
CVE ID: CVE-2022-49361 State: PUBLISHED Published: 2025-02-26T02:11:08.881Z Last Updated: 2025-07-11T17:19:16.905Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check for inline inode Yanming reported a kernel bug in Bugzilla kernel [1], which can be reproduced. The bug message is: The kernel message is shown below: kernel BUG at fs/inode.c:611! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 dput+0x2dd/0x720 do_renameat2+0x596/0x970 __x64_sys_rename+0x78/0x90 do_syscall_64+0x3b/0x90 [1] https://bugzilla.kernel.org/show_bug.cgi?id=215895 The bug is due to fuzzed inode has both inline_data and enc
/0x90 [1] https://bugzilla.kernel.org/show_bug.cgi?id=215895 The bug is due to fuzzed inode has both inline_data and encrypted flags. During f2fs_evict_inode(), as the inode was deleted by rename(), it will cause inline data conversion due to conflicting flags. The page cache will be polluted and the panic will be triggered in clear_inode(). Try fixing the bug by doing more sanity checks for inline data inode in sanity_check_inode(). References: - https://git.kernel.org/stable/c/efdefbe8b7564602ab446474788225a1f2a323b5 - https://git.kernel.org/stable/c/7cfe2d43becaf76e562b9617d2c2d9b445f86761 - https://git.kernel.org/stable/c/11c1cd032df85df3c096a57a7f27d57819956e4a - https://git.kernel.org/
617d2c2d9b445f86761 - https://git.kernel.org/stable/c/11c1cd032df85df3c096a57a7f27d57819956e4a - https://git.kernel.org/stable/c/198fd9faa271dd54dca6fc8eb6873f42dfd3b4d8 - https://git.kernel.org/stable/c/677a82b44ebf263d4f9a0cfbd576a6ade797a07b
CVE ID: CVE-2022-49362 State: PUBLISHED Published: 2025-02-26T02:11:09.344Z Last Updated: 2025-05-04T08:36:05.475Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix potential use-after-free in nfsd_file_put() nfsd_file_put_noref() can free @nf, so don't dereference @nf immediately upon return from nfsd_file_put_noref(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ada1757b259f353cade47037ee0a0249b4cddad3 - https://git.kernel.org/stable/c/261eabe19cb28e4a8587a4442d257b543d7c2d57 - https://git.kernel.org/stable/c/333dcc94ebf53f79f3dc0e7a7c16700bc7ff7e57 - https://git.kern
4a8587a4442d257b543d7c2d57 - https://git.kernel.org/stable/c/333dcc94ebf53f79f3dc0e7a7c16700bc7ff7e57 - https://git.kernel.org/stable/c/b6c71c66b0ad8f2b59d9bc08c7a5079b110bec01
CVE ID: CVE-2022-49363 State: PUBLISHED Published: 2025-02-26T02:11:09.817Z Last Updated: 2025-07-11T17:19:17.959Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on block address in f2fs_do_zero_range() As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215894 I have encountered a bug in F2FS file system in kernel v5.17. I have uploaded the system call sequence as case.c, and a fuzzed image can be found in google net disk The kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can reproduce the bug by running the following commands: kernel BUG at fs/f2fs/segm
SAN=y and CONFIG_KASAN_INLINE=y. You can reproduce the bug by running the following commands: kernel BUG at fs/f2fs/segment.c:2291! Call Trace: f2fs_invalidate_blocks+0x193/0x2d0 f2fs_fallocate+0x2593/0x4a70 vfs_fallocate+0x2a5/0xac0 ksys_fallocate+0x35/0x70 __x64_sys_fallocate+0x8e/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is, after image was fuzzed, block mapping info in inode will be inconsistent with SIT table, so in f2fs_fallocate(), it will cause panic when updating SIT with invalid blkaddr. Let's fix the issue by adding sanity check on block address before updating SIT table with it. References: - https://git.kernel.org/stable/c/7361c9f2bd6a8
ty check on block address before updating SIT table with it. References: - https://git.kernel.org/stable/c/7361c9f2bd6a8f0cbb41cdea9aff04765ff23f67 - https://git.kernel.org/stable/c/a34d7b49894b0533222188a52e2958750f830efd - https://git.kernel.org/stable/c/f2e1c38b5ac64eb1a16a89c52fb419409d12c25b - https://git.kernel.org/stable/c/470493be19a5730ed432e3ac0f29a2ee7fc6c557 - https://git.kernel.org/stable/c/805b48b234a2803cb7daec7f158af12f0fbaefac - https://git.kernel.org/stable/c/25f8236213a91efdf708b9d77e9e51b6fc3e141c
CVE ID: CVE-2022-49364 State: PUBLISHED Published: 2025-02-26T02:11:10.295Z Last Updated: 2025-07-11T17:19:19.040Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to clear dirty inode in f2fs_evict_inode() As Yanming reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215904 The kernel message is shown below: kernel BUG at fs/f2fs/inode.c:825! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 shrink_dentry_list+0x17c/0x4f0 shrink_dcache_parent+0x143/0x1e0 do_one_tree+0x9/0x30 shrink_dcache_for_umount+0x51/0x120 generic_shutdown_super+0x5c/0x3a0 kill_block_super+0x90/0xd0 kill_f2fs_super+0x225/0x310