[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cve-CVE-2024-27435":3},{"id":4,"cve_id":5,"euvd_id":6,"summary":7,"published":8,"cvss_data":9,"is_remote":20,"cwes":21,"cpes":23,"technologies":31,"references":33,"score":39,"epss_score":40,"epss_percentile":41,"is_kev":20,"cisa_kev_date_added":42,"cisa_kev_due_date":42,"cisa_ssvc":43,"attack_mappings":53,"exploits":69},55067,"CVE-2024-27435","EUVD-2024-24639","In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix reconnection fail due to reserved tag allocation\n\nWe found a issue on production environment while using NVMe over RDMA,\nadmin_q reconnect failed forever while remote target and network is ok.\nAfter dig into it, we found it may caused by a ABBA deadlock due to tag\nallocation. In my case, the tag was hold by a keep alive request\nwaiting inside admin_q, as we quiesced admin_q while reset ctrl, so the\nrequest maked as idle and will not process before reset success. As\nfabric_q shares tagset with admin_q, while reconnect remote target, we\nneed a tag for connect command, but the only one reserved tag was held\nby keep alive command which waiting inside admin_q. As a result, we\nfailed to reconnect admin_q forever. In order to fix this issue, I\nthink we should keep two reserved tags for admin queue.","2024-05-17T13:15:00Z",{"cvss_v3.1":10},{"scope":11,"version":12,"baseScore":13,"attackVector":14,"baseSeverity":15,"vectorString":16,"integrityImpact":17,"userInteraction":17,"attackComplexity":18,"availabilityImpact":19,"privilegesRequired":18,"confidentialityImpact":17},"UNCHANGED","3.1",5.5,"LOCAL","MEDIUM","CVSS:3.1\u002FAV:L\u002FAC:L\u002FPR:L\u002FUI:N\u002FS:U\u002FC:N\u002FI:N\u002FA:H","NONE","LOW","HIGH",false,[22],"CWE-667",[24,25,26,27,28,29,30],"cpe:2.3:o:linux:linux_kernel:5.12:rc4:*:*:*:*:*:*","cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","cpe:2.3:o:linux:linux_kernel:5.12:rc6:*:*:*:*:*:*","cpe:2.3:o:linux:linux_kernel:5.12:rc8:*:*:*:*:*:*","cpe:2.3:o:linux:linux_kernel:5.12:rc5:*:*:*:*:*:*","cpe:2.3:o:linux:linux_kernel:5.12:rc7:*:*:*:*:*:*","cpe:2.3:o:linux:linux_kernel:5.12:-:*:*:*:*:*:*",[32],"Linux Linux Kernel",[34,35,36,37,38],"https:\u002F\u002Fgit.kernel.org\u002Fstable\u002Fc\u002F149afee5c7418ec5db9d7387b9c9a5c1eb7ea2a8","https:\u002F\u002Fgit.kernel.org\u002Fstable\u002Fc\u002F262da920896e2f2ab0e3947d9dbee0aa09045818","https:\u002F\u002Fgit.kernel.org\u002Fstable\u002Fc\u002F6851778504cdb49431809b4ba061903d5f592c96","https:\u002F\u002Fgit.kernel.org\u002Fstable\u002Fc\u002Fde105068fead55ed5c07ade75e9c8e7f86a00d1d","https:\u002F\u002Fgit.kernel.org\u002Fstable\u002Fc\u002Fff2f90f88d78559802466ad1c84ac5bda4416b3a",0.28,0.00397,0.33688,null,{"timestamp":44,"automatable":45,"tech_impact":46,"exploitation":47,"cisa_decision":48,"cisa_remediation_timeline":52},"2024-05-31T18:39:12.435774Z","no","partial","none",{"vector":49,"decision":50,"priority":51},"CISAv1\u002FE:N\u002FA:N\u002FT:P\u002FM:H\u002F2026-10-25T19:09:11.588179\u002F","track_star","medium","60D",[54,60],{"name":55,"source":56,"tactics":57,"technique_id":59},"Exploitation for Privilege Escalation","attack_vector",[58],"privilege-escalation","T1068",{"name":61,"source":62,"cwe_ids":63,"tactics":64,"capec_ids":66,"technique_id":68},"Application or System Exploitation","capec",[22],[65],"impact",[67],"CAPEC-25","T1499.004",[]]