The Kernel flaw in the NVME found. There is a NULL pointer dereference in nvmet_setup_auth() introduced in commit db1312dd95488b5e6ff362ff66fcf953a46b1821 causing a DoS. A remote user can cause deny of service with the steps like these:
1. After configuring the NVME system, configure a bad 'dhchap_ctrl_key' on an allowed host (for example, 'DHHC-1:AAAA:').
2. From a remote client, use the nvme-cli util for easy communication to the remote target and run 'nvme connect' (to the remote target) to cause a Remote DoS on the target.
3. To bypass the Authentication feature (if you want to exploit the vulnerability from an unauthorized client), you can simply pass to the 'nvme connect' command the allowed client's NQN. To obtain the allowed NQN, a simple network sniffing could be done.
To summarize - a NULL Pointer Dereference vulnerability in the nvmet kernel module, in drivers/nvme/target/auth.c.
Created kernel tracking bugs for this issue:
Affects: fedora-all [bug 2157928]
Based on comment
, the CVE not required for this one, because existed in development code only ("Versions affected - v6.0-rc1 to v6.0-rc3 (fixed in v6.0-rc4)").
Keeping CVE. Based on comment by reporter:
"I firmly believe we should keep the CVE assigned and further encourage
similar assignments. I’ll try to explain why.
1. As a security researcher whose purpose is not to sell 0-day
vulnerabilities, the only benefit of reporting them, except for fixing
them, is getting CVEs assigned to them. Thus there is no reason for me
to wait and report them when a major kernel version is released.
2. Saying that “… so should not be in any release” isn’t entirely
correct. Although the vulnerability is in a release candidates
versions of the Linux kernel, it doesn’t mean that we can not see
these kernels in production servers since these kernel versions are
fully tested, work, and are available for the public."