CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50196 – pinctrl: ocelot: fix system hang on level based interrupts
https://notcve.org/view.php?id=CVE-2024-50196
In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ``` • https://git.kernel.org/stable/c/655f5d4662b958122b260be05aa6dfdf8768efe6 https://git.kernel.org/stable/c/4a81800ef05bea5a9896f199677f7b7f5020776a https://git.kernel.org/stable/c/20728e86289ab463b99b7ab4425515bd26aba417 https://git.kernel.org/stable/c/dcbe9954634807ec54e22bde278b5b269f921381 https://git.kernel.org/stable/c/93b8ddc54507a227087c60a0013ed833b6ae7d3c •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50195 – posix-clock: Fix missing timespec64 check in pc_clock_settime()
https://notcve.org/view.php?id=CVE-2024-50195
In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself. • https://git.kernel.org/stable/c/0606f422b453f76c31ab2b1bd52943ff06a2dcf2 https://git.kernel.org/stable/c/29f085345cde24566efb751f39e5d367c381c584 https://git.kernel.org/stable/c/e0c966bd3e31911b57ef76cec4c5796ebd88e512 https://git.kernel.org/stable/c/673a1c5a2998acbd429d6286e6cad10f17f4f073 https://git.kernel.org/stable/c/c8789fbe2bbf75845e45302cba6ffa44e1884d01 https://git.kernel.org/stable/c/27abbde44b6e71ee3891de13e1a228aa7ce95bfe https://git.kernel.org/stable/c/a3f169e398215e71361774d13bf91a0101283ac2 https://git.kernel.org/stable/c/1ff7247101af723731ea42ed565d54fb8 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50191 – ext4: don't set SB_RDONLY after filesystem errors
https://notcve.org/view.php?id=CVE-2024-50191
In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that. • https://git.kernel.org/stable/c/fbb177bc1d6487cd3e9b50ae0be2781b7297980d https://git.kernel.org/stable/c/4061e07f040a091f694f461b86a26cf95ae66439 https://git.kernel.org/stable/c/58c0648e4c773f5b54f0cb63bc8c7c6bf52719a9 https://git.kernel.org/stable/c/ee77c388469116565e009eaa704a60bc78489e09 https://git.kernel.org/stable/c/d3476f3dad4ad68ae5f6b008ea6591d1520da5d8 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50184 – virtio_pmem: Check device status before requesting flush
https://notcve.org/view.php?id=CVE-2024-50184
In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated. • https://git.kernel.org/stable/c/59ac565c6277d4be6661e81ea6a7f3ca2c5e4e36 https://git.kernel.org/stable/c/4ce662fe4be6fbc2595d9ef4888b2b6e778c99ed https://git.kernel.org/stable/c/9a2bc9b6f929a2ce1ebe4d1a796ddab37568c5b4 https://git.kernel.org/stable/c/6a5ca0ab94e13a1474bf7ad8437a975c2193618f https://git.kernel.org/stable/c/b01793cc63dd39c8f12b9a3d8dc115fbebb19e2a https://git.kernel.org/stable/c/ce7a3a62cc533c922072f328fd2ea2fd7cb893d4 https://git.kernel.org/stable/c/e25fbcd97cf52c3c9824d44b5c56c19673c3dd50 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50183 – scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance
https://notcve.org/view.php?id=CVE-2024-50183
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue. • https://git.kernel.org/stable/c/0857b1c573c0b095aa778bb26d8b3378172471b6 https://git.kernel.org/stable/c/0ef6e016eb53fad6dc44c3253945efb43a3486b9 https://git.kernel.org/stable/c/bbc525409bfe8e5bff12f5d18d550ab3e52cdbef https://git.kernel.org/stable/c/0a3c84f71680684c1d41abb92db05f95c09111e8 •