CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42296 – f2fs: fix return value of f2fs_convert_inline_inode()
https://notcve.org/view.php?id=CVE-2024-42296
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix return value of f2fs_convert_inline_inode() If device is readonly, make f2fs_convert_inline_inode() return EROFS instead of zero, otherwise it may trigger panic during writeback of inline inode's dirty page as below: f2fs_write_single_data_page+0xbb6/0x1e90 fs/f2fs/data.c:2888 f2fs_write_cache_pages fs/f2fs/data.c:3187 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3342 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3369 do_writepages+0x359/0x870 mm/page-writeback.c:2634 filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397 __filemap_fdatawrite_range mm/filemap.c:430 [inline] file_write_and_wait_range+0x1aa/0x290 mm/filemap.c:788 f2fs_do_sync_file+0x68a/0x1ae0 fs/f2fs/file.c:276 generic_write_sync include/linux/fs.h:2806 [inline] f2fs_file_write_iter+0x7bd/0x24e0 fs/f2fs/file.c:4977 call_write_iter include/linux/fs.h:2114 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa72/0xc90 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f • https://git.kernel.org/stable/c/70f5ef5f33c333cfb286116fa3af74ac9bc84f1b https://git.kernel.org/stable/c/47a8ddcdcaccd9b891db4574795e46a33a121ac2 https://git.kernel.org/stable/c/077f0e24b27c4b44841593c7edbd1993be9eecb5 https://git.kernel.org/stable/c/1e7725814361c8c008d131db195cef8274ff26b8 https://git.kernel.org/stable/c/a8eb3de28e7a365690c61161e7a07a4fc7c60bbf •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42295 – nilfs2: handle inconsistent state in nilfs_btnode_create_block()
https://notcve.org/view.php?id=CVE-2024-42295
In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle inconsistent state in nilfs_btnode_create_block() Syzbot reported that a buffer state inconsistency was detected in nilfs_btnode_create_block(), triggering a kernel bug. It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state. So, modify nilfs_btnode_create_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug. • https://git.kernel.org/stable/c/a60be987d45dd510aeb54389526f9957cfab106c https://git.kernel.org/stable/c/19cce46238ffe3546e44b9c74057103ff8b24c62 https://git.kernel.org/stable/c/02b87e6334a38c65eef49848d3f1ac422f0b2a44 https://git.kernel.org/stable/c/5f0a6800b8aec1b453c7fe4c44fcaac5ffe9d52e https://git.kernel.org/stable/c/e34191cce3ee63dfa5fb241904aaf2a042d5b6d8 https://git.kernel.org/stable/c/012be828a118bf496e666ef1fc47fc0e7358ada2 https://git.kernel.org/stable/c/be56dfc9be0604291267c07b0e27a69a6bda4899 https://git.kernel.org/stable/c/366c3f688dd0288cbe38af1d3a886b5c6 •
CVSS: 6.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42292 – kobject_uevent: Fix OOB access within zap_modalias_env()
https://notcve.org/view.php?id=CVE-2024-42292
In the Linux kernel, the following vulnerability has been resolved: kobject_uevent: Fix OOB access within zap_modalias_env() zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove. • https://git.kernel.org/stable/c/9b3fa47d4a76b1d606a396455f9bbeee083ef008 https://git.kernel.org/stable/c/81a15d28f32af01493ae8c5457e0d55314a4167d https://git.kernel.org/stable/c/b59a5e86a3934f1b6a5bd1368902dbc79bdecc90 https://git.kernel.org/stable/c/648d5490460d38436640da0812bf7f6351c150d2 https://git.kernel.org/stable/c/c5ee8adc8d98a49703320d13878ba2b923b142f5 https://git.kernel.org/stable/c/68d63ace80b76395e7935687ecdb86421adc2168 https://git.kernel.org/stable/c/57fe01d3d04276875c7e3a6dc763517fc05b8762 https://git.kernel.org/stable/c/d4663536754defff75ff1eca0aaebc41d • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42291 – ice: Add a per-VF limit on number of FDIR filters
https://notcve.org/view.php?id=CVE-2024-42291
In the Linux kernel, the following vulnerability has been resolved: ice: Add a per-VF limit on number of FDIR filters While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice. • https://git.kernel.org/stable/c/1f7ea1cd6a3748427512ccc9582e18cd9efea966 https://git.kernel.org/stable/c/8e02cd98a6e24389d476e28436d41e620ed8e559 https://git.kernel.org/stable/c/d62389073a5b937413e2d1bc1da06ccff5103c0c https://git.kernel.org/stable/c/292081c4e7f575a79017d5cbe1a0ec042783976f https://git.kernel.org/stable/c/6ebbe97a488179f5dc85f2f1e0c89b486e99ee97 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-42290 – irqchip/imx-irqsteer: Handle runtime power management correctly
https://notcve.org/view.php?id=CVE-2024-42290
In the Linux kernel, the following vulnerability has been resolved: irqchip/imx-irqsteer: Handle runtime power management correctly The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing: BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0 Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context. [ tglx: Rewrote change log, added Fixes tag ] • https://git.kernel.org/stable/c/0136afa08967f6e160b9b4e85a7a70e4180a8333 https://git.kernel.org/stable/c/a590e8dea3df2639921f874d763be961dd74e8f9 https://git.kernel.org/stable/c/3a2884a44e5cda192df1b28e9925661f79f599a1 https://git.kernel.org/stable/c/fa1803401e1c360efe6342fb41d161cc51748a11 https://git.kernel.org/stable/c/58c56735facb225a5c46fa4b8bbbe7f31d1cb894 https://git.kernel.org/stable/c/21bd3f9e7f924cd2fc892a484e7a50c7e1847565 https://git.kernel.org/stable/c/f8ae38f1dfe652779c7c613facbc257cec00ac44 https://git.kernel.org/stable/c/33b1c47d1fc0b5f06a393bb915db85baa •