Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
age migration: page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:"f30e" flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffff) page dumped because: VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ cut here ]------------ kernel BUG at include/linux/page_ref.h:184! invalid opcode: 0000 [#1] SMP CPU: 3 PID: 38 Comm: kcompactd0 Not tainted 5.15.0-rc5 RIP: 0010:migrate_page_move_mapping+0xac3/0xe70 Call Trace: ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrate_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560
x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrate_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 Before the time, we should make clean a concept, what does refcount means in page gotten from grab_cache_page_write_begin(). There are 2 situations: Situation 1: refcount is 3, page is created by __page_cache_alloc. TYPE_A - the write process is using this page TYPE_B - page is assigned to one certain mapping by calling __add_to_page_cache_locked() TYPE_C - page is added into pagevec list corresponding current cpu by calling lru_cache_add() Situation 2: refcount is 2, page is gotten from the mapping's tree TYPE_B - page has been
pu by calling lru_cache_add() Situation 2: refcount is 2, page is gotten from the mapping's tree TYPE_B - page has been assigned to one certain mapping TYPE_A - the write process is using this page (by calling page_cache_get_speculative()) Filesystem releases one refcount by calling put_page() in xxx_write_end(), the released refcount corresponds to TYPE_A (write task is using it). If there are any processes using a page, page migration process will skip the page by judging whether expected_page_refs() equals to page refcount. The BUG is caused by following process: PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_
0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // put page into cpu 0's pagevec (refcnf = 3, for page creation process) ubifs_write_end SetPagePrivate(page_a) // doesn't increase page count ! unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // traverse all pages in cpu 0's pagevec __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages isolate_migratepages_block get_page_unless_zero(page_a) // refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_mi
ro(page_a) // refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS doesn't increase the page refcount after setting private flag, which leads to page migration task believes the page is not used by any other processes, so the page is migrated. This causes concurrent accessing on page refcount between put_page() called by other process(eg. read process calls lru_
This causes concurrent accessing on page refcount between put_page() called by other process(eg. read process calls lru_cache_add) and page_ref_unfreeze() called by mi ---truncated--- References: - https://git.kernel.org/stable/c/c34ae24a2590fee96a3a7735ba2fa6cc52306221 - https://git.kernel.org/stable/c/4f75bab98565afd4f905059c56ec4caba88a7eec - https://git.kernel.org/stable/c/5aaa2c0f0052b02c4a982993d4c5bb68fb7cbe22 - https://git.kernel.org/stable/c/fbeb2139eed65e929ce806c6468e6601ade01b1b - https://git.kernel.org/stable/c/3b67db8a6ca83e6ff90b756d3da0c966f61cd37b
CVE ID: CVE-2021-47636 State: PUBLISHED Published: 2025-02-26T01:54:10.206Z Last Updated: 2025-10-01T19:57:08.785Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix read out-of-bounds in ubifs_wbuf_write_nolock() Function ubifs_wbuf_write_nolock() may access buf out of bounds in following process: ubifs_wbuf_write_nolock(): aligned_len = ALIGN(len, 8); // Assume len = 4089, aligned_len = 4096 if (aligned_len <= wbuf->avail) ... // Not satisfy if (wbuf->used) { ubifs_leb_write() // Fill some data in avail wbuf len -= wbuf->avail; // len is still not 8-bytes aligned aligned_len -= wbuf->avail; } n = aligned_len >> c->max_
il wbuf len -= wbuf->avail; // len is still not 8-bytes aligned aligned_len -= wbuf->avail; } n = aligned_len >> c->max_write_shift; if (n) { n <<= c->max_write_shift; err = ubifs_leb_write(c, wbuf->lnum, buf + written, wbuf->offs, n); // n > len, read out of bounds less than 8(n-len) bytes } , which can be catched by KASAN: ========================================================= BUG: KASAN: slab-out-of-bounds in ecc_sw_hamming_calculate+0x1dc/0x7d0 Read of size 4 at addr ffff888105594ff8 by task kworker/u8:4/128 Workqueue: writeback wb_workfn (flush-ubifs_0_0) Call Trace: kasan_report.cold+0x81/0x165 nand_write_page_swecc+0xa9/0x160 ubifs_leb_write+0xf2/0x1b0 [ubifs] ubifs_wbuf_write_nolo
: kasan_report.cold+0x81/0x165 nand_write_page_swecc+0xa9/0x160 ubifs_leb_write+0xf2/0x1b0 [ubifs] ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs] write_head+0xdc/0x1c0 [ubifs] ubifs_jnl_write_inode+0x627/0x960 [ubifs] wb_workfn+0x8af/0xb80 Function ubifs_wbuf_write_nolock() accepts that parameter 'len' is not 8 bytes aligned, the 'len' represents the true length of buf (which is allocated in 'ubifs_jnl_xxx', eg. ubifs_jnl_write_inode), so ubifs_wbuf_write_nolock() must handle the length read from 'buf' carefully to write leb safely. Fetch a reproducer in [Link]. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/5343575aa11c5d7044107d59d43f84aec013
alyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/5343575aa11c5d7044107d59d43f84aec01312b0 - https://git.kernel.org/stable/c/b80ccbec0e4804436c382d7dd60e943c386ed83a - https://git.kernel.org/stable/c/07a209fadee7b53b46858538e1177597273862e4 - https://git.kernel.org/stable/c/a7054aaf1909cf40489c0ec1b728fdcf79c751a6 - https://git.kernel.org/stable/c/e09fa5318d51f522e1af4fbaf8f74999355980c8 - https://git.kernel.org/stable/c/3b7fb89135a20587d57f8877c02e25003e9edbdf - https://git.kernel.org/stable/c/4f2262a334641e05f645364d5ade1f565c85f20b
CVE ID: CVE-2021-47637 State: PUBLISHED Published: 2025-02-26T01:54:10.709Z Last Updated: 2025-10-01T19:57:08.665Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix deadlock in concurrent rename whiteout and inode writeback Following hung tasks: [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132 [ 77.028820] Call Trace: [ 77.029027] schedule+0x8c/0x1b0 [ 77.029067] mutex_lock+0x50/0x60 [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs] [ 77.029117] __writeback_single_inode+0x43c/0x570 [ 77.029128] writeback_sb_inodes+0x259/0x740 [ 77.029148] wb_writeback+0x107/0x4d0 [ 77.029163] wb_workfn+0x162/0x7b0 [ 92.390442] t
writeback_sb_inodes+0x259/0x740 [ 77.029148] wb_writeback+0x107/0x4d0 [ 77.029163] wb_workfn+0x162/0x7b0 [ 92.390442] task:aa state:D stack: 0 pid: 1506 [ 92.390448] Call Trace: [ 92.390458] schedule+0x8c/0x1b0 [ 92.390461] wb_wait_for_completion+0x82/0xd0 [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110 [ 92.390472] writeback_inodes_sb_nr+0x14/0x20 [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs] [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs] [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs] [ 92.390571] vfs_rename+0xdb2/0x1170 [ 92.390580] do_renameat2+0x554/0x770 , are caused by concurrent rename whiteout and inode writeback processes: rename_whiteout(Thread 1) wb_workfn(Thread2) ubifs_ren
used by concurrent rename whiteout and inode writeback processes: rename_whiteout(Thread 1) wb_workfn(Thread2) ubifs_rename do_rename lock_4_inodes (Hold ui_mutex) ubifs_budget_space make_free_space shrink_liability __writeback_inodes_sb_nr bdi_split_work_to_wbs (Queue new wb work) wb_do_writeback(wb work) __writeback_single_inode ubifs_write_inode LOCK(ui_mutex) ↑ wb_wait_for_completion (Wait wb work) <-- deadlock! Reproducer (Detail program in [Link]): 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT) 2. Consume out of space before kernel(mdelay) doing budget for whiteout Fix it by doing whiteout space budget before locking ubifs inodes. BTW, it also fixes wrong goto ta
budget for whiteout Fix it by doing whiteout space budget before locking ubifs inodes. BTW, it also fixes wrong goto tag 'out_release' in whiteout budget error handling path(It should at least recover dir i_size and unlock 4 ubifs inodes). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/9dddc8211430fb851ddf0b168e3a00c6f66cc185 - https://git.kernel.org/stable/c/37bdf1ad592555ecda1d55b89f6e393e4c0589d1 - https://git.kernel.org/stable/c/83e42a78428fc354f5e2049935b84c8d8d29b787 - https://git.kernel.org/stable/c/c58af8564a7b08757173009030b74baf4b2b762b - https://git.kernel.org/stable/c/70e9090acc32348cedc5def0cd6d5c126efc97b9 - https://git.kernel.
173009030b74baf4b2b762b - https://git.kernel.org/stable/c/70e9090acc32348cedc5def0cd6d5c126efc97b9 - https://git.kernel.org/stable/c/8b278c8dcfb565cb65eceb62a38cbf7a7c326db5 - https://git.kernel.org/stable/c/afd427048047e8efdedab30e8888044e2be5aa9c
CVE ID: CVE-2021-47638 State: PUBLISHED Published: 2025-02-26T01:54:11.178Z Last Updated: 2025-10-01T19:57:08.545Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ubifs: rename_whiteout: Fix double free for whiteout_ui->data 'whiteout_ui->data' will be freed twice if space budget fail for rename whiteout operation as following process: rename_whiteout dev = kmalloc whiteout_ui->data = dev kfree(whiteout_ui->data) // Free first time iput(whiteout) ubifs_free_inode kfree(ui->data) // Double free! KASAN reports: ================================================================== BUG: KASAN: double-free or invalid-free in ubifs_free_
================================================================= BUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70 Call Trace: kfree+0x117/0x490 ubifs_free_inode+0x4f/0x70 [ubifs] i_callback+0x30/0x60 rcu_do_batch+0x366/0xac0 __do_softirq+0x133/0x57f Allocated by task 1506: kmem_cache_alloc_trace+0x3c2/0x7a0 do_rename+0x9b7/0x1150 [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 Freed by task 1506: kfree+0x117/0x490 do_rename.cold+0x53/0x8a [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 The buggy address belongs to the object at ffff88810238bed8 which belongs to the cache kmalloc-8 of size 8 ==============================================
object at ffff88810238bed8 which belongs to the cache kmalloc-8 of size 8 ================================================================== Let ubifs_free_inode() free 'whiteout_ui->data'. BTW, delete unused assignment 'whiteout_ui->data_len = 0', process 'ubifs_evict_inode() -> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' doesn't need it (because 'inc_nlink(whiteout)' won't be excuted by 'goto out_release', and the nlink of whiteout inode is 0). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8b3c7be16f3f4dfd6e15ac651484e59d3fa36274 - https://git.kernel.org/stable/c/2b3236ecf96db7af5836e1366ce39ace8ce832fa - https://git.kernel.org/st
51484e59d3fa36274 - https://git.kernel.org/stable/c/2b3236ecf96db7af5836e1366ce39ace8ce832fa - https://git.kernel.org/stable/c/14276d38c89a170363e90b6ac0a53c3cf61b87fc - https://git.kernel.org/stable/c/a90e2dbe66d2647ff95a0442ad2e86482d977fd8 - https://git.kernel.org/stable/c/2ad07009c459e56ebdcc089d850d664660fdb742 - https://git.kernel.org/stable/c/b9a937f096e608b3368c1abc920d4d640ba2c94f - https://git.kernel.org/stable/c/6d7a158a7363c1f6604aa47ae1a280a5c65123dd - https://git.kernel.org/stable/c/40a8f0d5e7b3999f096570edab71c345da812e3e
CVE ID: CVE-2021-47639 State: PUBLISHED Published: 2025-02-26T01:54:11.651Z Last Updated: 2025-05-04T07:15:18.607Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn't zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requiremen
r issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns. The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren't accessible by the guest, and KVM won't read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal. WARNI
irty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal. WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: <TASK> kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_zap_invalidated_roots+0x50/0x90 [kvm] kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm] set_nx_huge_pages+0xb4/0x190 [kvm] param_attr_store+0x70/0x100 module_attr_store+0x19/0x30 kernfs_fop_write_iter+0x119/0x1b0 new_sync_write+0x11c/0x1b0 vfs_writ
_attr_store+0x70/0x100 module_attr_store+0x19/0x30 kernfs_fop_write_iter+0x119/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1cc/0x270 ksys_write+0x5f/0xe0 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/af47248407c0c5ae52a752af1ab5ce5b0db91502 - https://git.kernel.org/stable/c/0c8a8da182d4333d9bbb9131d765145568c847b2 - https://git.kernel.org/stable/c/8cf6f98ab1d16d5e607635a0c21c4231eb15367e - https://git.kernel.org/stable/c/d62007edf01f5c11f75d0f4b1e538fc52a5b1982
CVE ID: CVE-2021-47640 State: PUBLISHED Published: 2025-02-26T01:54:12.130Z Last Updated: 2025-10-01T19:57:08.385Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix early region not updated correctly The shadow's page table is not updated when PTE_RPN_SHIFT is 24 and PAGE_SHIFT is 12. It not only causes false positives but also false negative as shown the following text. Fix it by bringing the logic of kasan_early_shadow_page_entry here. 1. False Positive: ================================================================== BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50 Write of size 16 at addr f57f3b
============================ BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50 Write of size 16 at addr f57f3be0 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1 Call Trace: [c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable) [c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300 [c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200 [c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0 [c80d1cc0] [c03018a4] memset+0x34/0x90 [c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50 [c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570 [c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0 [c80d1db0] [c2036580] init_sd+0xc4/0x1d0 [c80
te+0xfc/0x570 [c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0 [c80d1db0] [c2036580] init_sd+0xc4/0x1d0 [c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c [c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384 [c80d1ef0] [c0004b14] kernel_init+0x24/0x170 [c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64 Memory state around the buggy address: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================
8 f8 f8 f8 f8 f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== 2. False Negative (with KASAN tests): ================================================================== Before fix: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039 KASAN failure expected in "((volatile char *)area)[3100]", but none occurred not ok 46 - vmalloc_oob not ok 1 - kasan ================================================================== After fix: ok 1 - kasan Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7f19245c3647afea8c7c41f795506ef70f64b9f2 - https:
- CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7f19245c3647afea8c7c41f795506ef70f64b9f2 - https://git.kernel.org/stable/c/f39a3309393a4a484532f6ba745c6acbcfe06115 - https://git.kernel.org/stable/c/5a3d8f3192a409893c57808cc935e16484df1068 - https://git.kernel.org/stable/c/de56beace6648065d404cd9835aa7d30e3df519d - https://git.kernel.org/stable/c/e3d157a4b4f4e0268c98be5b7013bf4b31234bb6 - https://git.kernel.org/stable/c/dd75080aa8409ce10d50fb58981c6b59bf8707d3
CVE ID: CVE-2021-47641 State: PUBLISHED Published: 2025-02-26T01:54:12.680Z Last Updated: 2025-10-01T19:57:08.118Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: video: fbdev: cirrusfb: check pixclock to avoid divide by zero Do a sanity check on pixclock value to avoid divide by zero. If the pixclock value is zero, the cirrusfb driver will round up pixclock to get the derived frequency as close to maxclock as possible. Syzkaller reported a divide error in cirrusfb_check_pixclock. divide error: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX,
SAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfb_check_var+0x6f1/0x1260 Call Trace: fb_set_var+0x398/0xf90 do_fb_ioctl+0x4b8/0x6f0 fb_ioctl+0xeb/0x130 __x64_sys_ioctl+0x19d/0x220 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c656d04247a2654ede5cead2ecbf83431dad5261 - https://git.kernel.org/stable/c/1d3fb46439ad4e8f0c5739eb33d1875ac9e0f135 - https://git.kernel.org/stable/c/40b13e3d85744210db13457785646634e2d056bd - https://git.kernel.org/stable/c/53a2088a396cfa1da92690a
t.kernel.org/stable/c/40b13e3d85744210db13457785646634e2d056bd - https://git.kernel.org/stable/c/53a2088a396cfa1da92690a1da289634cd73bf0d - https://git.kernel.org/stable/c/8c7e2141fb89c620ab4e41512e262fbf25b8260d - https://git.kernel.org/stable/c/6fe23ff94e7840097202e85c148688940b37c9b1 - https://git.kernel.org/stable/c/45800c42ef000f417270bcfc08630e42486fca99 - https://git.kernel.org/stable/c/e498b504f8c81b07efab9febf8503448de4dc9cf - https://git.kernel.org/stable/c/5c6f402bdcf9e7239c6bc7087eda71ac99b31379
CVE ID: CVE-2021-47642 State: PUBLISHED Published: 2025-02-26T01:54:13.193Z Last Updated: 2025-05-04T07:15:22.072Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow Coverity complains of a possible buffer overflow. However, given the 'static' scope of nvidia_setup_i2c_bus() it looks like that can't happen after examiniing the call sites. CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW) 1. fixed_size_dest: You might overrun the 48-character fixed-size string chan->adapter.name by copying name without checking the length. 2. parameter_as_source: Note:
haracter fixed-size string chan->adapter.name by copying name without checking the length. 2. parameter_as_source: Note: This defect has an elevated risk because the source argument is a parameter of the current function. 89 strcpy(chan->adapter.name, name); Fix this warning by using strscpy() which will silence the warning and prevent any future buffer overflows should the names used to identify the channel become much longer. References: - https://git.kernel.org/stable/c/47e5533adf118afaf06d25a3e2aaaab89371b1c5 - https://git.kernel.org/stable/c/580e5d3815474b8349250c25c16416585a72c7fe - https://git.kernel.org/stable/c/72dd5c46a152136712a55bf026a9aa8c1b12b60d - https://git.kernel.org/stable
416585a72c7fe - https://git.kernel.org/stable/c/72dd5c46a152136712a55bf026a9aa8c1b12b60d - https://git.kernel.org/stable/c/055cdd2e7b992921424d4daaa285ced787fb205f - https://git.kernel.org/stable/c/08dff482012758935c185532b1ad7d584785a86e - https://git.kernel.org/stable/c/9ff2f7294ab0f011cd4d1b7dcd9a07d8fdf72834 - https://git.kernel.org/stable/c/6a5226e544ac043bb2d8dc1bfe8920d02282f7cd - https://git.kernel.org/stable/c/41baa86b6c802cdc6ab8ff2d46c083c9be93de81 - https://git.kernel.org/stable/c/37a1a2e6eeeb101285cd34e12e48a881524701aa
CVE ID: CVE-2021-47643 State: PUBLISHED Published: 2025-02-26T01:54:13.684Z Last Updated: 2025-05-04T07:15:23.510Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: ir_toy: free before error exiting Fix leak in error path. References: - https://git.kernel.org/stable/c/99e3f83539cac6884a4df02cb204a57a184ea12b - https://git.kernel.org/stable/c/2011363c196846c083649c91ed30aeef64358d52 - https://git.kernel.org/stable/c/382e0f6958ef34eb093127b6d74c12f3b8fd0904 - https://git.kernel.org/stable/c/93ef3fdf3b6633c58f049e5a6be755777dde4340 - https://git.kernel.org/stable/c/52cdb013036391d9d87aba5b4fc49cdfc6ea4b23
CVE ID: CVE-2021-47644 State: PUBLISHED Published: 2025-02-26T01:54:14.179Z Last Updated: 2025-10-01T19:57:07.968Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: staging: media: zoran: move videodev alloc Move some code out of zr36057_init() and create new functions for handling zr->video_dev. This permit to ease code reading and fix a zr->video_dev memory leak. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8dce4b265a5357731058f69645840dabc718c687 - https://git.kernel.org/stable/c/bd01629315ffd5b63da91d0bd529a77d30e55028 - https://git.kernel.org/stable/c/ff3357bffd9fb78f
ps://git.kernel.org/stable/c/bd01629315ffd5b63da91d0bd529a77d30e55028 - https://git.kernel.org/stable/c/ff3357bffd9fb78f59762d8955afc7382a279079 - https://git.kernel.org/stable/c/c1ba65100a359fe28cfe37e09e10c99f247cbf1e - https://git.kernel.org/stable/c/1e501ec38796f43e995731d1bcd4173cb1ccfce0 - https://git.kernel.org/stable/c/82e3a496eb56da0b9f29fdc5b63cedb3289e91de