Race Condition Affecting kernel-zfcpdump-modules package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.05% (18th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Race Condition vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-RHEL9-KERNELZFCPDUMPMODULES-7023392
  • published23 May 2024
  • disclosed21 May 2024

Introduced: 21 May 2024

CVE-2023-52786  (opens in a new tab)
CWE-362  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:9 kernel-zfcpdump-modules.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-modules package and not the kernel-zfcpdump-modules package as distributed by RHEL. See How to fix? for RHEL:9 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix racy may inline data check in dio write

syzbot reports that the following warning from ext4_iomap_begin() triggers as of the commit referenced below:

    if (WARN_ON_ONCE(ext4_has_inline_data(inode)))
            return -ERANGE;

This occurs during a dio write, which is never expected to encounter an inode with inline data. To enforce this behavior, ext4_dio_write_iter() checks the current inline state of the inode and clears the MAY_INLINE_DATA state flag to either fall back to buffered writes, or enforce that any other writers in progress on the inode are not allowed to create inline data.

The problem is that the check for existing inline data and the state flag can span a lock cycle. For example, if the ilock is originally locked shared and subsequently upgraded to exclusive, another writer may have reacquired the lock and created inline data before the dio write task acquires the lock and proceeds.

The commit referenced below loosens the lock requirements to allow some forms of unaligned dio writes to occur under shared lock, but AFAICT the inline data check was technically already racy for any dio write that would have involved a lock cycle. Regardless, lift clearing of the state bit to the same lock critical section that checks for preexisting inline data on the inode to close the race.

CVSS Scores

version 3.1