Page 291 of 3179 results (0.022 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: f2fs: remove clear SB_INLINECRYPT flag in default_options In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again • https://git.kernel.org/stable/c/38a82c8d00638bb642bef787eb1d5e0e4d3b7d71 https://git.kernel.org/stable/c/724429db09e21ee153fef35e34342279d33df6ae https://git.kernel.org/stable/c/a9cea0489c562c97cd56bb345e78939f9909e7f4 https://git.kernel.org/stable/c/eddeb8d941d5be11a9da5637dbe81ac37e8449a2 https://git.kernel.org/stable/c/ae39c8ec4250d2a35ddaab1c40faacfec306ff66 https://git.kernel.org/stable/c/ac5eecf481c29942eb9a862e758c0c8b68090c33 •

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

In the Linux kernel, the following vulnerability has been resolved: Avoid hw_desc array overrun in dw-axi-dmac I have a use case where nr_buffers = 3 and in which each descriptor is composed by 3 segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put() handles the hw_desc considering the descs_allocated, this scenario would result in a kernel panic (hw_desc array will be overrun). To fix this, the proposal is to add a new member to the axi_dma_desc structure, where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in axi_desc_put() to handle the hw_desc array correctly. Additionally I propose to remove the axi_chan_start_first_queued() call after completing the transfer, since it was identified that unbalance can occur (started descriptors can be interrupted and transfer ignored due to DMA channel not being enabled). • https://git.kernel.org/stable/c/7c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5 https://git.kernel.org/stable/c/dd42570018f5962c10f215ad9c21274ed5d3541e https://git.kernel.org/stable/c/e151ae1ee065cf4b8ce4394ddb9d9c8df6370c66 https://git.kernel.org/stable/c/9004784e8d68bcd1ac1376407ba296fa28f04dbe https://git.kernel.org/stable/c/333e11bf47fa8d477db90e2900b1ed3c9ae9b697 •

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

In the Linux kernel, the following vulnerability has been resolved: f2fs: don't set RO when shutting down f2fs Shutdown does not check the error of thaw_super due to readonly, which causes a deadlock like below. f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread - bdev_freeze - freeze_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - set RO - waiting - bdev_thaw - thaw_super_locked - return -EINVAL, if sb_rdonly() - f2fs_stop_discard_thread -> wait for kthread_stop(discard_thread); • https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563 https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7 •

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

In the Linux kernel, the following vulnerability has been resolved: MIPS: Octeon: Add PCIe link status check The standard PCIe configuration read-write interface is used to access the configuration space of the peripheral PCIe devices of the mips processor after the PCIe link surprise down, it can generate kernel panic caused by "Data bus error". So it is necessary to add PCIe link status check for system protection. When the PCIe link is down or in training, assigning a value of 0 to the configuration address can prevent read-write behavior to the configuration space of peripheral PCIe devices, thereby preventing kernel panic. • https://git.kernel.org/stable/c/6bff05aaa32c2f7e1f6e68e890876642159db419 https://git.kernel.org/stable/c/64845ac64819683ad5e51b668b2ed56ee3386aee https://git.kernel.org/stable/c/6c1b9fe148a4e03bbfa234267ebb89f35285814a https://git.kernel.org/stable/c/25998f5613159fe35920dbd484fcac7ea3ad0799 https://git.kernel.org/stable/c/d996deb80398a90dd3c03590e68dad543da87d62 https://git.kernel.org/stable/c/1c33fd17383f48f679186c54df78542106deeaa0 https://git.kernel.org/stable/c/38d647d509543e9434b3cc470b914348be271fe9 https://git.kernel.org/stable/c/29b83a64df3b42c88c0338696feb6fdcd •

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

In the Linux kernel, the following vulnerability has been resolved: serial: imx: Introduce timeout when waiting on transmitter empty By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock. In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue. • https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7 https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916 https://git.kernel.org/stable/c/982ae3376c4c91590d38dc8a676c10f7df048a44 https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701 https://git.kernel.org/stable/c/e533e4c62e9993e62e947ae9bbec34e4c7ae81c2 https://access.redhat.com/security/cve/CVE-2024-40967 https://bugzilla.redhat.com/show_bug.cgi?id=2297551 • CWE-833: Deadlock •