Homepage

Time-of-check Time-of-use (TOCTOU) Affecting kernel-zfcpdump package, versions *

Severity

 Recommended
low

Based on default assessment until relevant scores are available.

Threat Intelligence

EPSS
0.12% (3rd 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 IDSNYK-CENTOS10-KERNELZFCPDUMP-18154929
  • published22 Jul 2026
  • disclosed19 Jul 2026
Report a new vulnerability Found a mistake?

Introduced: 19 Jul 2026

NewCVE-2026-63874  (opens in a new tab)
CWE-367  (opens in a new tab)

How to fix?

There is no fixed version for Centos:10 kernel-zfcpdump.

NVD Description

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

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

net: mctp: usb: fix race between urb completion and rx_retry cancellation

It's possible that sequencing between setting ->stopped and cancelling the rx_retry work (in ndo_stop) could leave us with an urb queued:

T1: ndo_stop                  T2: rx_retry_work
------------                  ----------------
                              LD: ->stopped => false
ST: ->stopped <= true
usb_kill_urb()
                              mctp_usb_rx_queue()
                                usb_submit_urb()
cancel_delayed_work_sync()

That urb completion can then re-schedule rx_retry_work.

Strenghen the sequencing between the stop (preventing another requeue) and the cancel by updating both atomically under a new rx lock. After setting ->rx_stopped, and cancelling pending work, we know that the requeue cannot occur, so all that's left is killing any pending urb.