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: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42294 – block: fix deadlock between sd_remove & sd_release
https://notcve.org/view.php?id=CVE-2024-42294
In the Linux kernel, the following vulnerability has been resolved: block: fix deadlock between sd_remove & sd_release Our test report the following hung task: [ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds. [ 2538.459427] Call trace: [ 2538.459430] __switch_to+0x174/0x338 [ 2538.459436] __schedule+0x628/0x9c4 [ 2538.459442] schedule+0x7c/0xe8 [ 2538.459447] schedule_preempt_disabled+0x24/0x40 [ 2538.459453] __mutex_lock+0x3ec/0xf04 [ 2538.459456] __mutex_lock_slowpath+0x14/0x24 [ 2538.459459] mutex_lock+0x30/0xd8 [ 2538.459462] del_gendisk+0xdc/0x350 [ 2538.459466] sd_remove+0x30/0x60 [ 2538.459470] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459474] device_release_driver+0x18/0x28 [ 2538.459478] bus_remove_device+0x15c/0x174 [ 2538.459483] device_del+0x1d0/0x358 [ 2538.459488] __scsi_remove_device+0xa8/0x198 [ 2538.459493] scsi_forget_host+0x50/0x70 [ 2538.459497] scsi_remove_host+0x80/0x180 [ 2538.459502] usb_stor_disconnect+0x68/0xf4 [ 2538.459506] usb_unbind_interface+0xd4/0x280 [ 2538.459510] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459514] device_release_driver+0x18/0x28 [ 2538.459518] bus_remove_device+0x15c/0x174 [ 2538.459523] device_del+0x1d0/0x358 [ 2538.459528] usb_disable_device+0x84/0x194 [ 2538.459532] usb_disconnect+0xec/0x300 [ 2538.459537] hub_event+0xb80/0x1870 [ 2538.459541] process_scheduled_works+0x248/0x4dc [ 2538.459545] worker_thread+0x244/0x334 [ 2538.459549] kthread+0x114/0x1bc [ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds. [ 2538.461014] Call trace: [ 2538.461016] __switch_to+0x174/0x338 [ 2538.461021] __schedule+0x628/0x9c4 [ 2538.461025] schedule+0x7c/0xe8 [ 2538.461030] blk_queue_enter+0xc4/0x160 [ 2538.461034] blk_mq_alloc_request+0x120/0x1d4 [ 2538.461037] scsi_execute_cmd+0x7c/0x23c [ 2538.461040] ioctl_internal_command+0x5c/0x164 [ 2538.461046] scsi_set_medium_removal+0x5c/0xb0 [ 2538.461051] sd_release+0x50/0x94 [ 2538.461054] blkdev_put+0x190/0x28c [ 2538.461058] blkdev_release+0x28/0x40 [ 2538.461063] __fput+0xf8/0x2a8 [ 2538.461066] __fput_sync+0x28/0x5c [ 2538.461070] __arm64_sys_close+0x84/0xe8 [ 2538.461073] invoke_syscall+0x58/0x114 [ 2538.461078] el0_svc_common+0xac/0xe0 [ 2538.461082] do_el0_svc+0x1c/0x28 [ 2538.461087] el0_svc+0x38/0x68 [ 2538.461090] el0t_64_sync_handler+0x68/0xbc [ 2538.461093] el0t_64_sync+0x1a8/0x1ac T1: T2: sd_remove del_gendisk __blk_mark_disk_dead blk_freeze_queue_start ++q->mq_freeze_depth bdev_release mutex_lock(&disk->open_mutex) sd_release scsi_execute_cmd blk_queue_enter wait_event(!q->mq_freeze_depth) mutex_lock(&disk->open_mutex) SCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in this scenario. This is a classic ABBA deadlock. • https://git.kernel.org/stable/c/eec1be4c30df73238b936fa9f3653773a6f8b15c https://git.kernel.org/stable/c/5a5625a83eac91fdff1d5f0202ecfc45a31983c9 https://git.kernel.org/stable/c/f5418f48a93b69ed9e6a2281eee06b412f14a544 https://git.kernel.org/stable/c/7e04da2dc7013af50ed3a2beb698d5168d1e594b •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42293 – arm64: mm: Fix lockless walks with static and dynamic page-table folding
https://notcve.org/view.php?id=CVE-2024-42293
In the Linux kernel, the following vulnerability has been resolved: arm64: mm: Fix lockless walks with static and dynamic page-table folding Lina reports random oopsen originating from the fast GUP code when 16K pages are used with 4-level page-tables, the fourth level being folded at runtime due to lack of LPA2. In this configuration, the generic implementation of p4d_offset_lockless() will return a 'p4d_t *' corresponding to the 'pgd_t' allocated on the stack of the caller, gup_fast_pgd_range(). This is normally fine, but when the fourth level of page-table is folded at runtime, pud_offset_lockless() will offset from the address of the 'p4d_t' to calculate the address of the PUD in the same page-table page. This results in a stray stack read when the 'p4d_t' has been allocated on the stack and can send the walker into the weeds. Fix the problem by providing our own definition of p4d_offset_lockless() when CONFIG_PGTABLE_LEVELS <= 4 which returns the real page-table pointer rather than the address of the local stack variable. • https://git.kernel.org/stable/c/0dd4f60a2c76938c2625f6c630c225699d97608b https://git.kernel.org/stable/c/78672d49d3eebbcda3589f4d6e589caf357c5a59 https://git.kernel.org/stable/c/36639013b3462c06ff8e3400a427f775b4fc97f5 •
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 •