libceph: Reject monmaps advertising zero monitors
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.271, 5.15.216, 6.1.183, 6.6.148, 6.12.101, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the "BUG_ON(monc->monmap->num_mon < 1)" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop "log output for unusual values of num_mon" part ]
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
From ba75bb98cfb93b62c54af25bf67ff90857264bbe · fixed in ba5f0015bfd376d764163045a61c17be75f44dae; From ba75bb98cfb93b62c54af25bf67ff90857264bbe · fixed in caf082ef8609a6ac26159ce115f55ab7d00231a3; From ba75bb98cfb93b62c54af25bf67ff90857264bbe · fixed in e3ccd4ecab09b22f507f49cb7ed9990c7158ceab; From ba75bb98cfb93b62c54af25bf67ff90857264bbe · fixed in 0591a15815b498be628a937146e44487d599ba33; From ba75bb98cfb93b62c54af25bf67ff90857264bbe · fixed in cd0d41bc569632eaaeccde9d2a6bc919ec00c407; From ba75bb98cfb93b62c54af25bf67ff90857264bbe · fixed in e67e8b694872c9bc66996040f9de9242f6236ed9; From ba75bb98cfb93b62c54af25bf67ff90857264bbe · fixed in 3b249546f59c3d6d3592c10657f82bc3f1faa07c; From ba75bb98cfb93b62c54af25bf67ff90857264bbe · fixed in 40480eee361ed9676b3f844d532ac28b47251634
- Linux Linux
2.6.34
- KernelLinux
From 2.6.34 · fixed in 5.10.271; From 5.11.0 · fixed in 5.15.216; From 5.16.0 · fixed in 6.1.183; From 6.2.0 · fixed in 6.6.148; From 6.7.0 · fixed in 6.12.101; From 6.13.0 · fixed in 6.18.42; From 6.19.0 · fixed in 7.1.6
References 8
git.kernel.org
- stable/c/ba5f0015bfd376d764163045a61c17be75f44dae
- stable/c/caf082ef8609a6ac26159ce115f55ab7d00231a3
- stable/c/e3ccd4ecab09b22f507f49cb7ed9990c7158ceab
- stable/c/0591a15815b498be628a937146e44487d599ba33
- stable/c/cd0d41bc569632eaaeccde9d2a6bc919ec00c407
- stable/c/e67e8b694872c9bc66996040f9de9242f6236ed9
- stable/c/3b249546f59c3d6d3592c10657f82bc3f1faa07c
- stable/c/40480eee361ed9676b3f844d532ac28b47251634