Page 176 of 4387 results (0.019 seconds)

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to truncate preallocated blocks in f2fs_file_open() chenyuwen reports a f2fs bug as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000011 fscrypt_set_bio_crypt_ctx+0x78/0x1e8 f2fs_grab_read_bio+0x78/0x208 f2fs_submit_page_read+0x44/0x154 f2fs_get_read_data_page+0x288/0x5f4 f2fs_get_lock_data_page+0x60/0x190 truncate_partial_data_page+0x108/0x4fc f2fs_do_truncate_blocks+0x344/0x5f0 f2fs_truncate_blocks+0x6c/0x134 f2fs_truncate+0xd8/0x200 f2fs_iget+0x20c/0x5ac do_garbage_collect+0x5d0/0xf6c f2fs_gc+0x22c/0x6a4 f2fs_disable_checkpoint+0xc8/0x310 f2fs_fill_super+0x14bc/0x1764 mount_bdev+0x1b4/0x21c f2fs_mount+0x20/0x30 legacy_get_tree+0x50/0xbc vfs_get_tree+0x5c/0x1b0 do_new_mount+0x298/0x4cc path_mount+0x33c/0x5fc __arm64_sys_mount+0xcc/0x15c invoke_syscall+0x60/0x150 el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0xa0 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec It is because inode.i_crypt_info is not initialized during below path: - mount - f2fs_fill_super - f2fs_disable_checkpoint - f2fs_gc - f2fs_iget - f2fs_truncate So, let's relocate truncation of preallocated blocks to f2fs_file_open(), after fscrypt_file_open(). • https://git.kernel.org/stable/c/d4dd19ec1ea0cf6532d65709325c42b1398614a8 https://git.kernel.org/stable/c/5f04969136db674f133781626e0b692c5f2bf2f0 https://git.kernel.org/stable/c/f44a25a8bfe0c15d33244539696cd9119cf44d18 https://git.kernel.org/stable/c/3ba0ae885215b325605ff7ebf6de12ac2adf204d https://git.kernel.org/stable/c/298b1e4182d657c3e388adcc29477904e9600ed5 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix array-index-out-of-bounds in diFree • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/55b732c8b09b41148eaab2fa8e31b0af47671e00 https://git.kernel.org/stable/c/9b3a4345957f5372041bc4f59de322f62653e862 https://git.kernel.org/stable/c/538a27c8048f081a5ddd286f886eb986fbbc7f80 https://git.kernel.org/stable/c/63f7fdf733add82f126ea00e2e48f6eba15ac4b9 https://git.kernel.org/stable/c/8d8f9a477de0d7962342eedf2a599215b7c63d28 https://git.kernel.org/stable/c/ff14eadc278663cac69d57d3ca7fb2f394e1f8a7 https://git.kernel.org/stable/c/6aa6892a90a5a7fabffe5692ab9f06a7a •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null reference error when checking end of zone This patch fixes a potentially null pointer being accessed by is_end_zone_blkaddr() that checks the last block of a zone when f2fs is mounted as a single device. • https://git.kernel.org/stable/c/e067dc3c6b9c419bac43c6a0be2d85f44681f863 https://git.kernel.org/stable/c/381cbe85592c78fbaeb3e770e3e9f3bfa3e67efb https://git.kernel.org/stable/c/c82bc1ab2a8a5e73d9728e80c4c2ed87e8921a38 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: dma: fix call order in dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 • https://git.kernel.org/stable/c/9ac7849e35f705830f7b016ff272b0ff1f7ff759 https://git.kernel.org/stable/c/fe2d246080f035e0af5793cb79067ba125e4fb63 https://git.kernel.org/stable/c/2f7bbdc744f2e7051d1cb47c8e082162df1923c9 https://git.kernel.org/stable/c/257193083e8f43907e99ea633820fc2b3bcd24c7 https://git.kernel.org/stable/c/87b34c8c94e29fa01d744e5147697f592998d954 https://git.kernel.org/stable/c/f993a4baf6b622232e4c190d34c220179e5d61eb https://git.kernel.org/stable/c/1fe97f68fce1ba24bf823bfb0eb0956003473130 https://git.kernel.org/stable/c/22094f5f52e7bc16c5bf9613365049383 •

CVSS: -EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: md: fix deadlock between mddev_suspend and flush bio Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue. T1. the first flush is at the ending stage, it clears 'mddev->flush_bio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flush_bio', and attempts to queue md_submit_flush_data(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc active_io and tries to flush, but is blocked because 'mddev->flush_bio' is not NULL (set by T2). T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc by T3. T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request . mddev->flush_bio = bio . queue submit_flushes . . . . • https://git.kernel.org/stable/c/f9f2d957a8ea93c73182aebf7de30935a58c027d https://git.kernel.org/stable/c/530cec617f5a8ba6f26bcbf0d64d75c951d17730 https://git.kernel.org/stable/c/fa2bbff7b0b4e211fec5e5686ef96350690597b5 https://git.kernel.org/stable/c/c4c2345214b66e2505a26fd2ea58839dd7a1d48d https://git.kernel.org/stable/c/32226070813140234b6c507084738e8e8385c5c6 https://git.kernel.org/stable/c/2d0738a8322bf4e5bfe693d16b3111928a9ccfbf https://git.kernel.org/stable/c/ca963eefbc3331222b6121baa696d49ba2008811 https://git.kernel.org/stable/c/611d5cbc0b35a752e657a83eebadf40d8 •