[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"repo-stars":3,"vuln-DEBIAN-CVE-2024-42232":6},{"stargazers_count":4,"fetched_at":5},7,"2026-06-04T08:53:30.047Z",{"id":7,"descriptions":8,"cisa":9,"weaknesses":10,"exploits":11,"aliases":12,"duplicate_of":9,"upstream":13,"downstream":16,"duplicates":21,"related":22,"reserved_at":9,"published_at":23,"modified_at":24,"state":9,"summary":25,"references_raw":27,"kevs":34,"epss":9,"epss_history":35,"metrics":36,"affected":43},"DEBIAN-CVE-2024-42232","In the Linux kernel, the following vulnerability has been resolved:  libceph: fix race between delayed_work() and ceph_monc_stop()  The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting().  Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic.  This part was missed in commit b5d91704f53e (\"libceph: behave in mon_fault() if cur_mon \u003C 0\") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.  To fix this:  - clear monc->cur_mon and monc->hunting as part of closing the session   in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how   it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed",null,[],[],[],[14],{"_key":15},"CVE-2024-42232",[17,19],{"_key":18},"DLA-4008-1",{"_key":20},"DSA-5747-1",[],[],"2024-08-07T16:15:46.213Z","2026-04-28T20:28:23.419505Z",{"cisa_kev":26,"cisa_ransomware":26,"cisa_vendor":9,"epss_severity":9,"epss_score":9,"severity":9,"severity_score":9,"severity_version":9,"severity_source":9,"severity_vector":9,"severity_status":9},false,[28],{"url":29,"sources":30,"tags":32},"https://security-tracker.debian.org/tracker/CVE-2024-42232",[31],"osv_debian",[33],"Advisory",[],[],[37],{"source":31,"cvss_v2_0":9,"cvss_v3_0":9,"cvss_v3_1":38,"cvss_v4_0":9},{"baseScore":39,"baseSeverity":9,"vectorString":40,"impactScore":41,"exploitabilityScore":42},5.5,"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",6,4.6,[44,63],{"ecosystem":45,"name":46,"vendor":47,"product":46,"cpe_part":9,"purl_type":48,"purl_namespace":47,"purl_name":46,"source":9,"versions":49},"Debian","linux","debian","deb",[50,56,59,62],{"version":51,"is_range":52,"range_type":53,"version_start":9,"version_start_type":9,"version_end":54,"version_end_type":55,"fixed_in":9},"lt5_10_223_1",true,"ecosystem","5.10.223-1","excluding",{"version":57,"is_range":52,"range_type":53,"version_start":9,"version_start_type":9,"version_end":58,"version_end_type":55,"fixed_in":9},"lt6_1_106_1","6.1.106-1",{"version":60,"is_range":52,"range_type":53,"version_start":9,"version_start_type":9,"version_end":61,"version_end_type":55,"fixed_in":9},"lt6_9_10_1","6.9.10-1",{"version":60,"is_range":52,"range_type":53,"version_start":9,"version_start_type":9,"version_end":61,"version_end_type":55,"fixed_in":9},{"ecosystem":45,"name":64,"vendor":47,"product":64,"cpe_part":9,"purl_type":48,"purl_namespace":47,"purl_name":64,"source":9,"versions":65},"linux-6.1",[66],{"version":67,"is_range":52,"range_type":53,"version_start":9,"version_start_type":9,"version_end":68,"version_end_type":55,"fixed_in":9},"lt6_1_119_1~deb11u1","6.1.119-1~deb11u1"]