Improper Input Validation Affecting kernel-zfcpdump-devel package, versions *


Severity

Recommended
low

Based on Red Hat Enterprise Linux security rating

    Threat Intelligence

    EPSS
    0.04% (11th 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 ID SNYK-RHEL8-KERNELZFCPDUMPDEVEL-6544672
  • published 4 Apr 2024
  • disclosed 3 Apr 2024

How to fix?

There is no fixed version for RHEL:8 kernel-zfcpdump-devel.

NVD Description

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

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

md: Don't ignore read-only array in md_check_recovery()

Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem.

After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh:

  1. array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb

  2. register new sync thread concurrently.

  3. dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro

  4. stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))

  5. sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread);

  6. daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;

The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression.

CVSS Scores

version 3.1
Expand this section

Red Hat

4.4 medium
  • Attack Vector (AV)
    Local
  • Attack Complexity (AC)
    Low
  • Privileges Required (PR)
    High
  • User Interaction (UI)
    None
  • Scope (S)
    Unchanged
  • Confidentiality (C)
    None
  • Integrity (I)
    None
  • Availability (A)
    High
Expand this section

SUSE

5.5 medium