Januscape: 16 ఏళ్ల నాటి KVM లోపం గెస్ట్ VMని హోస్ట్‌కి ఎస్కేప్ అవ్వడానికి అనుమతిస్తుంది

టెనెంట్ల మధ్య ఉన్న గోడలో పగుళ్లు వచ్చాయి

క్లౌడ్ కంప్యూటింగ్ యొక్క మొత్తం హామీ ఒక నిశ్శబ్ద ఊహపై ఆధారపడి ఉంటుంది: మీరు అద్దెకు తీసుకునే వర్చువల్ మెషిన్ అది రన్ అయ్యే ఫిజికల్ హోస్ట్‌ను తాకలేదు, మరియు దాని పక్కన ఉన్న మరొకరి VMను ఖచ్చితంగా తాకలేదు. ఆ గోడను hypervisor isolation అంటారు, మరియు Linuxలో ఇది KVM ద్వారా అమలు చేయబడుతుంది — ఇది ప్రపంచంలోని చాలా పెద్ద సంఖ్యలో ఉన్న క్లౌడ్ సర్వర్‌లను నడిపే Kernel-based Virtual Machine.

జూలై 4, 2026న, Linux kernel maintainers పదహారేళ్లుగా ఆ గోడను బలహీనపరిచిన ఒక లోపాన్ని మూసివేయడానికి అత్యవసర stable releases సిరీస్‌ను విడుదల చేశారు. CVE-2026-53359గా గుర్తించబడిన మరియు "Januscape" అని పిలువబడే ఈ లోపం, ఒక సాధారణ guest VM లోపల నడిచే కోడ్‌ను Intel మరియు AMD సిస్టమ్‌లు రెండింటిలోనూ host kernelను కరప్ట్ చేయడానికి అనుమతిస్తుంది. ప్యాచ్ విడుదలవడం వల్ల దీని వివరాలు బహిరంగమయ్యాయి, మరియు పబ్లిక్ ఫిక్స్ ఉన్న చోట త్వరలోనే పబ్లిక్ exploit కూడా వస్తుంది కాబట్టి ఇది ఇప్పుడు చాలా ముఖ్యం.

అసలు Januscape అంటే ఏమిటి

Januscape అనేది ఒక use-after-free సెక్యూరిటీ లోపం. సరళంగా చెప్పాలంటే, ఒక మెమరీ భాగాన్ని తిరిగి ఇచ్చేసి వేరొక దాని కోసం మళ్లీ ఉపయోగించిన తర్వాత కూడా ఒక ప్రోగ్రామ్ ఆ మెమరీని ఉపయోగిస్తూనే ఉన్నప్పుడు use-after-free జరుగుతుంది — నివాసితులు ఖాళీ చేసి కొత్తవారు వచ్చిన తర్వాత కూడా పాత చిరునామాకు ఉత్తరం పంపడం లాంటిది. దాడి చేసే వ్యక్తి ఆ "freed" ప్రదేశంలో సిస్టమ్‌ను దేనినైనా రాయమని చేయగలిగితే, అది ఇంకా అసలైన, విశ్వసనీయ డేటాగానే పరిగణించబడుతుంది.

ఈ బగ్ KVM యొక్క shadow MMUలో ఉంది. ఒక guest VM రన్ అయినప్పుడు, దానికి సొంత మెమరీ అడ్రస్‌లు ఉంటాయి, కానీ అవి host యొక్క నిజమైన అడ్రస్‌లు కావు. ఈ రెండింటి మధ్య అనువాదం చేయడానికి ఏదైనా ఒకటి ఉండాలి, అదే memory management unit. అనేక కాన్ఫిగరేషన్‌లలో KVM ఈ అనువాదాన్ని guest టేబుల్‌లను host యొక్క నిజమైన టేబుల్‌లలోకి మిర్రర్ చేసే "shadow" page tables ఉపయోగించి సాఫ్ట్‌వేర్‌లో చేస్తుంది. Januscape అనేది ఆ shadow-MMU emulationలోని ఒక లోపం: కేవలం guest-side చర్యలతోనే, దాడి చేసే వ్యక్తి host kernel యొక్క shadow pageని కరప్ట్ చేయగలడు — అంటే guestని హద్దుల్లో ఉంచాల్సిన నిర్మాణాన్ని దెబ్బతీయగలడు.

"Intel మరియు AMD రెండూ" ఎందుకు భయపెట్టే విషయం

చాలా వరకు virtual-machine escape బగ్‌లు నిర్దిష్ట vendor-specific గా ఉంటాయి. అవి Intel యొక్క VT-x లేదా AMD యొక్క AMD-V లోపాలను ఉపయోగించుకుంటాయి, కాబట్టి ఒక చిప్‌ని ఉపయోగించే ప్రొవైడర్‌కు ప్రమాదం ఉంటే మరొకరు సురక్షితంగా ఉంటారు. Januscape వేరు. ఇది రెండు వెండర్ల వ్యాప్తంగా KVM పంచుకునే shadow-MMU కోడ్‌లో ఉంటుంది, అందుకే Intel మరియు AMD x86 సిస్టమ్‌లు రెండింటిలోనూ ట్రిగ్గర్ చేయగల మొదటి guest-to-host escapeగా ఇది వర్ణించబడింది.

మిశ్రమ హార్డ్‌వేర్ కలిగిన క్లౌడ్ ఆపరేటర్‌కు, ఇది సాధారణంగా ఉండే ఎスケープ మార్గాన్ని తొలగిస్తుంది. తమ ఫ్లీట్‌ను తరలించడానికి ఎటువంటి "సురక్షితమైన" ప్రాసెసర్ లేదు. దెబ్బతిన్న కోడ్ రన్ అయ్యే ప్రతిచోటా ఈ ఒకే టెక్నిక్ పనిచేస్తుంది.

అసలు ఇది ఎంత తీవ్రమైనది

బహిరంగంగా విడుదల చేయబడిన proof-of-concept కొంతవరకు తక్కువ నష్టాన్ని కలిగిస్తుంది: ఇది hostను panic చేస్తుంది. అది హాని లేనిదేమీ కాదు — ఆ panic మొత్తం physical machineను మరియు దానిపై ఉన్న ప్రతి tenant VMని క్రాష్ చేస్తుంది, ఇది ఆ బాక్స్‌లో ఉన్న ప్రతిఒక్కరికీ denial-of-service కలిగిస్తుంది.

అంతకంటే ఘోరమైన విషయం ఏమిటంటే విడుదల చేయని భాగం. ఈ బగ్‌ను కనుగొని రిపోర్ట్ చేసిన సెక్యూరిటీ పరిశోధకుడు Hyunwoo Kim (@v4bel), ఒక ప్రత్యేకమైన, విడుదల కాని exploit ద్వారా ఇదే లోపాన్ని ఉపయోగించి పూర్తి host code execution సాధించవచ్చని పేర్కొన్నారు. అది అత్యంత భయంకరమైన పరిస్థితి: ఒక చౌకైన VM నుండి దాడి చేసే వ్యక్తి కోడ్ hostగా రన్ అవుతూ, పక్కనే ఉన్న ప్రతి tenant machineను చదవగలదు మరియు మార్చగలదు. సరిగ్గా ఈ రకమైన పూర్తి guest-to-host escape కోసం 250,000 US dollars వరకు చెల్లించే Google యొక్క kvmCTF రివార్డ్ ప్రోగ్రామ్‌కు zero-dayగా సమర్పించేంత తీవ్రమైనది ఈ బగ్. మరియు ఇది సుమారు పదహారేళ్ల పాటు ఎవరికీ కనిపించకుండా దాగి ఉంది.

అసలు ఎవరికి ప్రమాదం ఉంది

ఇది మీకు క్రియాశీల ముప్పుగా మారడానికి రెండు షరతులు నిజం కావాలి:

మీరు untrusted guestsను అనుమతిస్తే. Public clouds, VPS providers, shared CI/CD runners, sandbox services — మీరు నడిపే హార్డ్‌వేర్‌పై తెలియని వ్యక్తి VMని స్పిన్ అప్ చేయగల ఏ ప్రదేశమైనా.

మీరు nested virtualizationను ఎనేబుల్ చేసి ఉంటే. దాడి జరిగే మార్గం ఆ guests కోసం nested virt ఎనేబుల్ చేయడంపై ఆధారపడి ఉంటుంది.

మీరు మీ స్వంత వర్క్‌లోడ్‌లను మాత్రమే హోస్ట్ చేసే single-tenant serverను ఉపయోగిస్తుంటే, మీ ప్రమాదం చాలా తక్కువగా ఉంటుంది — దాడి చేసే వ్యక్తి ఇప్పటికే మీ స్వంత VMలలో ఒకదాని లోపల ఉండాలి. కానీ మీరు కంప్యూట్‌ను విక్రయిస్తున్నా లేదా షేర్ చేస్తున్నా, దీనిని అత్యవసరమైనదిగా పరిగణించండి.

అడుగు 1: మీకు ప్రమాదం ఉందో లేదో తెలుసుకోండి

రన్ అవుతున్న kernel version మరియు nested virtualization ఎనేబుల్ చేయబడిందో లేదో తనిఖీ చేయండి:

# Which kernel am I running?
uname -r

# Is nested virtualization on? (Intel host)
cat /sys/module/kvm_intel/parameters/nested

# Or on an AMD host
cat /sys/module/kvm_amd/parameters/nested

ఏదైనా ఒక కమాండ్ తిరిగి ఇస్తే Y (లేదా 1) మరియు మీ kernel కింద పేర్కొన్న fixed releases కంటే పాతదైతే, మీకు ప్రమాదం ఉన్నట్లే.

అడుగు 2: సరిచేయబడిన Kernelకి Patch చేయండి

సరిచేయబడిన stable kernels జూలై 4, 2026న విడుదలయ్యాయి. వీటిలో కనీసం ఒకదానికి అప్‌డేట్ చేసి, రీబూట్ చేయండి:

7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260

చాలా డిస్ట్రిబ్యూషన్‌లలో ఇది సాధారణ package update:

sudo apt update && sudo apt full-upgrade   # Debian / Ubuntu
sudo dnf update kernel                       # Fedora / RHEL family
# then reboot into the new kernel
sudo reboot

దీనితో నిర్ధారించండి uname -r రీబూట్ తర్వాత మీరు patched buildలో ఉన్నారని.

అడుగు 3: మీరు వెంటనే Patch చేయలేకపోతే, Nested Virtualizationని డిసేబుల్ చేయండి

untrusted guestsను అనుమతించే కానీ వెంటనే రీబూట్ చేయలేని hosts కోసం, nested virtualizationను తొలగించడం దాడి మార్గాన్ని అడ్డుకుంటుంది:

# Intel host
echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.conf

# AMD host
echo "options kvm_amd nested=0" | sudo tee /etc/modprobe.d/kvm-no-nested.conf

ఇది అమలులోకి రావడానికి moduleను రీలోడ్ చేయండి (లేదా రీబూట్ చేయండి). దీని వల్ల కలిగే పరిణామాన్ని అర్థం చేసుకోండి: ఇది మీ టెనెంట్లు ఆధారపడే ఏదైనా చెల్లుబాటు అయ్యే nested virtualizationని నిలిపివేస్తుంది — VMs లోపల నడిచే VMs. ఇది తాత్కాలిక ఉపశమనం (stopgap) మాత్రమే, kernel patchకు ప్రత్యామ్నాయం కాదు.

ముగింపు

Januscape అనేది క్లౌడ్ కంప్యూటింగ్‌లోని అత్యంత బలమైన గోడ ఇప్పటికీ సాఫ్ట్‌వేర్‌తోనే నిర్మించబడిందని, మరియు పదహారేళ్ల క్రితం రాసిన సాఫ్ట్‌వేర్ ఒక చిన్న పొరపాటును చాలా కాలం దాచిపెట్టి మొత్తం పరిశ్రమనే ముప్పులోకి నెట్టగలదని గుర్తుచేస్తోంది. మంచి వార్త ఏమిటంటే దీనికి పరిష్కారం ఇప్పటికే అందుబాటులో ఉంది మరియు mitigation సులభం. కంప్యూట్‌ను షేర్ చేసే ప్రతి ఆపరేటర్ చేయాల్సిన పని స్పష్టంగా ఉంది: మీ kernelను తనిఖీ చేయండి, patch చేయండి మరియు ఈ రోజు patch చేయలేకపోతే, patch చేసే వరకు nested virtualizationని ఆపివేయండి. పబ్లిక్ patch మరియు పబ్లిక్ weaponized exploit మధ్య సమయం నెలల్లో కాదు, రోజుల్లోనే ఉంటుంది.

ప్రయోజనాలు

• పరిష్కారం ఇప్పటికే ఉంది. లోపం బహిరంగమైన రోజే Patched stable kernels విడుదలయ్యాయి, కాబట్టి remediation అనేది సాధారణ update మాత్రమే, పరిశోధన ప్రాజెక్ట్ కాదు.
• స్పష్టమైన, తక్షణ mitigation. Nested virtualizationని డిసేబుల్ చేయడం వల్ల మీరు కొత్త kernelలోకి రీబూట్ చేయడానికి ముందే దాడి మార్గం మూసివేయబడుతుంది.
• Coordinated disclosure పనిచేసింది. Google యొక్క kvmCTF reward program ద్వారా బగ్ maintainersకి చేరింది, మరియు weaponized exploit వచ్చే ముందే patch విడుదల చేయబడింది.

పరిమితులు

• పదహారేళ్ల నిశ్శబ్ద ప్రమాదం. వెల్లడించడానికి ముందు ఈ లోపాన్ని ఎవరూ నిశ్శబ్దంగా ఉపయోగించలేదని కచ్చితంగా చెప్పలేము.
• Cross-vendor పరిధి. ఇది shared shadow-MMU కోడ్‌లో ఉన్నందున, ఉపయోగించడానికి సురక్షితమైన Intel లేదా AMD చిప్ ఏదీ లేదు.
• ఒక full-RCE exploit ప్రైవేట్‌గా ఉంది. పబ్లిక్ PoC కేవలం hostను క్రాష్ చేస్తుంది, కానీ విడుదల చేయని బలమైన వెర్షన్ host code execution సాధిస్తుందని పరిశోధకుడు ధృవీకరించారు.

హెచ్చరిక

పబ్లిక్ proof-of-conceptను ప్రమాద పరిమితిగా భావించవద్దు. అది hostను panic మాత్రమే చేస్తుంది; అసలైన ప్రమాదం full host execution పొందే ప్రైవేట్ exploit. మీరు multi-tenant infrastructureను నడుపుతున్నట్లయితే, సౌలభ్యం కంటే kernel patchకే ప్రాధాన్యత ఇవ్వండి, మరియు దీనితో uname -r ప్రతి host నిజంగా fixed buildలోకి రీబూట్ అయిందో లేదో తనిఖీ చేయండి — ప్యాచ్ చేసిన package ఉండి కూడా పాత kernelపై రన్ అవుతుంటే అది దేనినీ రక్షించదు.

తరచుగా అడిగే ప్రశ్నలు

ఇది నా వ్యక్తిగత ల్యాప్‌టాప్ లేదా డెస్క్‌టాప్‌పై ప్రభావం చూపుతుందా? పరోక్షంగా మాత్రమే. మీరు nested virtualizationతో untrusted guest VMsను నడపకపోతే, మీరు ఈ దాడి లక్ష్యం కాదు — కానీ మీ kernelను patch చేయడం మంచి పద్ధతి.

Nested virtualizationని డిసేబుల్ చేయడం మాత్రమే సరిపోతుందా? ఇది untrusted guests కోసం తెలిసిన దాడి మార్గాన్ని తొలగిస్తుంది, కానీ ఇది తాత్కాలిక ఉపశమనం మాత్రమే. వీలైనంత త్వరగా kernel patchను వర్తింపజేయండి మరియు patched hostsలో మాత్రమే nested virtని తిరిగి ఎనేబుల్ చేయండి.

నా క్లౌడ్ ప్రొవైడర్ దీనిని నా కోసం సరిచేయగలరా? ప్రధాన ప్రొవైడర్లు తమ వైపు host hypervisorను patch చేస్తారు; మీ స్వంత guest VMs దెబ్బతినే భాగాలు కావు. ఒకవేళ మీరు అయితే ఆ ప్రొవైడర్ — కంప్యూట్‌ను రీసెల్ చేస్తున్నా లేదా shared runners నడుపుతున్నా — ఆ బాధ్యత మీదే.

దీనికి "Januscape" అని ఎందుకు పేరు పెట్టారు? ఈ పేరు రెండు ముఖాలు కలిగిన రోమన్ దేవుడైన Janusను గుర్తుకు తెస్తుంది — x86 ప్రపంచంలోని Intel మరియు AMD రెండు ముఖాలకూ వర్తించే లోపానికి ఇది సరిగ్గా సరిపోతుంది.

ట్యాగ్‌లు

security, linux, virtualization, kvm, cve