Januscape: 16-ବର୍ଷର KVM ତ୍ରୁଟି ଯାହା Guest VM କୁ Host କୁ Escape କରିବାକୁ ଦେଇଥାଏ

Tenants ମାନଙ୍କ ମଧ୍ୟରେ ଥିବା କାନ୍ଥ ଭାଙ୍ଗିଗଲା

କ୍ଲାଉଡ୍ କମ୍ପ୍ୟୁଟିଂର ସମ୍ପୂର୍ଣ୍ଣ ପ୍ରତିଶ୍ରୁତି ଗୋଟିଏ ସାଧାରଣ ଧାରଣା ଉପରେ ଆଧାରିତ: ଆପଣ ଭଡ଼ାରେ ନେଉଥିବା virtual machine ଟି ଏହା ଚାଲୁଥିବା physical host କୁ ସ୍ପର୍ଶ କରିପାରିବ ନାହିଁ, ଏବଂ ଏହା ପାଖରେ ଥିବା ଅନ୍ୟ ଜଣଙ୍କର VM କୁ ମଧ୍ୟ ସ୍ପର୍ଶ କରିପାରିବ ନାହିଁ। ସେହି କାନ୍ଥକୁ hypervisor isolation କୁହାଯାଏ, ଏବଂ Linux ରେ ଏହା KVM ଦ୍ୱାରା ଲାଗୁ କରାଯାଏ — Kernel-based Virtual Machine ଯାହା ବିଶ୍ୱର ବିଶାଳ ପରିମାଣର କ୍ଲାଉଡ୍ ସର୍ଭରଗୁଡ଼ିକୁ ସଞ୍ଚାଳିତ କରେ।

ଜୁଲାଇ 4, 2026 ରେ, Linux kernel ମେଣ୍ଟେନରମାନେ ଷୋହଳ ବର୍ଷ ଧରି ସେହି କାନ୍ଥକୁ ଦୁର୍ବଳ କରୁଥିବା ଏକ ତ୍ରୁଟିକୁ ବନ୍ଦ କରିବା ପାଇଁ ଜରୁରୀକାଳୀନ stable ରିଲିଜ୍ ସିରିଜ୍ ଜାରି କରିଥିଲେ। CVE-2026-53359 ଭାବରେ ଟ୍ରାକ୍ କରାଯାଇଥିବା ଏବଂ "Januscape" ଡାକନାମ ଦିଆଯାଇଥିବା ଏହି ତ୍ରୁଟି, ଏକ ସାଧାରଣ guest VM ଭିତରେ ଚାଲୁଥିବା କୋଡ୍ କୁ host kernel କୁ କ୍ଷତିଗ୍ରସ୍ତ କରିବାକୁ ଦେଇଥାଏ — ଉଭୟ Intel ଏବଂ AMD ସିଷ୍ଟମରେ। ଏହା ଏବେ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ କାରଣ ପାଚ୍ ରିଲିଜ୍ ହେବାର ଅର୍ଥ ହେଉଛି ବିବରଣୀ ସାର୍ବଜନୀନ ହୋଇସାରିଛି, ଏବଂ ଯେଉଁଠାରେ ସାର୍ବଜନୀନ ଫିକ୍ସ ଥାଏ, ସେଠାରେ ଶୀଘ୍ର ସାର୍ବଜନୀନ exploit ମଧ୍ୟ ଆସିଯାଏ।

ପ୍ରକୃତରେ Januscape କ’ଣ

Januscape ହେଉଛି ଏକ use-after-free vulnerability। ସରଳ ଭାଷାରେ, use-after-free ସେତେବେଳେ ଘଟେ ଯେତେବେଳେ ଏକ ପ୍ରୋଗ୍ରାମ୍ ମେମୋରୀର ଏକ ଅଂଶକୁ ହସ୍ତାନ୍ତର କରାଯିବା ଏବଂ ଅନ୍ୟ କିଛି ପାଇଁ ପୁନଃ ବ୍ୟବହାର କରାଯିବା ପରେ ମଧ୍ୟ ବ୍ୟବହାର କରିଚାଲେ — ଯେପରି ଭଡ଼ାଟିଆମାନେ ଘର ଛାଡ଼ିବା ଏବଂ ଅଜଣା ଲୋକମାନେ ରହିବା ପରେ ସେହି ଠିକଣାକୁ ଏକ ଚିଠି ପଠାଇବା। ଆକ୍ରମଣକାରୀ ସିଷ୍ଟମକୁ ସେହି "freed" ସ୍ଥାନରେ ଲେଖିବା ପାଇଁ ଯାହା ବି ପ୍ରବର୍ତ୍ତାଇପାରେ, ତାହାକୁ ଏପରି ବ୍ୟବହାର କରାଯାଏ ସେପରି ଏହା ଏବେ ବି ମୂଳ, ବିଶ୍ୱସନୀୟ ଡାଟା।

ଏହି ବଗ୍ KVM ର shadow MMU ରେ ରହିଛି। ଯେତେବେଳେ ଏକ guest VM ଚାଲେ, ଏହାର ମେମୋରୀ ଆଡ୍ରେସ୍ ବିଷୟରେ ନିଜସ୍ୱ ଧାରଣା ଥାଏ, କିନ୍ତୁ ସେଗୁଡ଼ିକ host ର ପ୍ରକୃତ ଆଡ୍ରେସ୍ ନୁହଁନ୍ତି। ଏହି ଦୁଇଟି ମଧ୍ୟରେ ଅନୁବାଦ କରିବାକୁ କିଛି ଦରକାର, ଏବଂ ସେହି ଜିନିଷଟି ହେଉଛି memory management unit। ଅନେକ କନଫିଗରେସନରେ KVM "shadow" page tables ବ୍ୟବହାର କରି ସଫ୍ଟୱେର୍ ରେ ଏହି ଅନୁବାଦ କରେ ଯାହା guest ର ଟେବୁଲଗୁଡ଼ିକୁ host ର ପ୍ରକୃତ ଟେବୁଲଗୁଡ଼ିକରେ ମିରର କରେ। Januscape ସେହି shadow-MMU ଏମୁଲେସନରେ ଏକ ତ୍ରୁଟି: କେବଳ guest-side କାର୍ଯ୍ୟାନୁଷ୍ଠାନ ଦ୍ୱାରା, ଜଣେ ଆକ୍ରମଣକାରୀ host kernel ର shadow page କୁ କ୍ଷତିଗ୍ରସ୍ତ କରିପାରିବ — ସେହି ଗଠନ ଯାହା guest କୁ ସୀମିତ ରଖିବା କଥା।

"ଉଭୟ Intel ଏବଂ AMD" କାହିଁକି ଡରାଇବା ଭଳି କଥା

ଅଧିକାଂଶ virtual-machine escape ବଗ୍‌ଗୁଡ଼ିକ ଭେଣ୍ଡର-ନିର୍ଦ୍ଦିଷ୍ଟ ଅଟନ୍ତି। ସେଗୁଡ଼ିକ Intel ର VT-x କିମ୍ବା AMD ର AMD-V ର ଏକ ତ୍ରୁଟିର ଫାଇଦା ଉଠାନ୍ତି, ଫଳରେ ଗୋଟିଏ ଚିପ୍ ଚଲାଉଥିବା ପ୍ରୋଭାଇଡର୍ ପ୍ରଭାବିତ ହେଉଥିବା ବେଳେ ଅନ୍ୟଟି ସୁରକ୍ଷିତ ଥାଏ। Januscape ଅଲଗା। ଏହା shadow-MMU କୋଡ୍ ରେ ଅଛି ଯାହାକୁ KVM ଉଭୟ ଭେଣ୍ଡର ମଧ୍ୟରେ ସେୟାର କରେ, ସେଥିପାଇଁ ଏହାକୁ ଉଭୟ 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 ର ମେସିନ୍ କୁ ପଢ଼ିବା ଏବଂ ପୁନଃ ଲେଖିବା ପାଇଁ ସକ୍ଷମ ହୁଏ। ଏହି ବଗ୍ ଯଥେଷ୍ଟ ଗୁରୁତର ଥିଲା ଯେ ଏହାକୁ Google ର kvmCTF ରେ zero-day ଭାବରେ ଦାଖଲ କରାଯାଇଥିଲା, ଯାହା ନିୟନ୍ତ୍ରିତ ପୁରସ୍କାର ପ୍ରୋଗ୍ରାମ୍ ଯାହା ଏହି ପ୍ରକାରର ସମ୍ପୂର୍ଣ୍ଣ guest-to-host escape ପାଇଁ 250,000 US dollars ପର୍ଯ୍ୟନ୍ତ ପ୍ରଦାନ କରେ। ଏବଂ ଏହା ପ୍ରାୟ ଷୋହଳ ବର୍ଷ ଧରି ସମସ୍ତଙ୍କ ଆଖି ସାମ୍ନାରେ ଲୁଚି ରହିଥିଲା।

ପ୍ରକୃତରେ କାହା ପାଇଁ ବିପଦ ରହିଛି

ଆପଣଙ୍କ ପାଇଁ ଏହା ଏକ ସକ୍ରିୟ ବିପଦ ହେବାକୁ ଦୁଇଟି ସର୍ତ୍ତ ସତ ହେବା ଆବଶ୍ୟକ:

ଆପଣ ଅବିଶ୍ୱସ୍ତ guests ଗ୍ରହଣ କରନ୍ତି। Public clouds, VPS providers, shared CI/CD runners, sandbox services — ଯେଉଁଠାରେ ଜଣେ ଅଜଣା ବ୍ୟକ୍ତି ଆପଣ ଚଲାଉଥିବା ହାର୍ଡୱେର୍ ରେ ଏକ VM ସୃଷ୍ଟି କରିପାରିବ।

ଆପଣ nested virtualization ସୁବିଧା ପ୍ରଦାନ କରନ୍ତି। ଆକ୍ରମଣ ପଥ ସେହି guests ମାନଙ୍କ ପାଇଁ nested virt ସକ୍ଷମ ହେବା ଉପରେ ନିର୍ଭର କରେ।

ଯଦି ଆପଣ ଏକ single-tenant ସର୍ଭର ଚଲାଉଛନ୍ତି ଯାହା କେବଳ ଆପଣଙ୍କ ନିଜର ୱାର୍କଲୋଡ୍ ହୋଷ୍ଟ କରେ, ତେବେ ଆପଣଙ୍କ ବିପଦ ବହୁତ କମ୍ — ଆକ୍ରମଣକାରୀଙ୍କୁ ପୂର୍ବରୁ ଆପଣଙ୍କର କୌଣସି ଗୋଟିଏ VM ଭିତରେ ରହିବାକୁ ପଡ଼ିବ। କିନ୍ତୁ ଯଦି ଆପଣ କମ୍ପ୍ୟୁଟ୍ ବିକ୍ରି କରନ୍ତି କିମ୍ବା ସେୟାର କରନ୍ତି, ତେବେ ଏହାକୁ ଜରୁରୀ ବୋଲି ଭାବନ୍ତୁ।

Step 1: ଆପଣ ପ୍ରଭାବିତ କି ନୁହଁନ୍ତି ଜାଣନ୍ତୁ

ଚାଲୁଥିବା kernel ସଂସ୍କରଣ ଏବଂ 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 ତଳେ ଦିଆଯାଇଥିବା ଫିକ୍ସଡ୍ ରିଲିଜ୍ ପୂର୍ବର ହୋଇଥାଏ, ତେବେ ଆପଣ ପ୍ରଭାବିତ ପରିସରଭୁକ୍ତ।

Step 2: ଏକ ଫିକ୍ସଡ୍ Kernel କୁ ପାଚ୍ କରନ୍ତୁ

ଫିକ୍ସଡ୍ 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

ଅଧିକାଂଶ ଡିଷ୍ଟ୍ରିବ୍ୟୁସନ୍‌ରେ ଏହା ଏକ ସାଧାରଣ ପ୍ୟାକେଜ୍ ଅପଡେଟ୍:

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 ବିଲ୍ଡରେ ଅଛନ୍ତି।

Step 3: ଯଦି ଆପଣ ତୁରନ୍ତ ପାଚ୍ କରିପାରିବେ ନାହିଁ, nested virtualization ନିଷ୍କ୍ରିୟ କରନ୍ତୁ

ଯେଉଁ hosts ଗୁଡ଼ିକ ଅବିଶ୍ୱସ୍ତ guests ଗ୍ରହଣ କରନ୍ତି କିନ୍ତୁ ତୁରନ୍ତ ରିବୁଟ୍ କରିପାରିବେ ନାହିଁ, 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

ଏହା କାର୍ଯ୍ୟକାରୀ ହେବା ପାଇଁ ମଡ୍ୟୁଲ୍ କୁ ରିଲୋଡ୍ କରନ୍ତୁ (କିମ୍ବା ରିବୁଟ୍ କରନ୍ତୁ)। ଏହାର ସୀମାବଦ୍ଧତା ବୁଝନ୍ତୁ: ଏହା ଆପଣଙ୍କ tenants ନିର୍ଭର କରୁଥିବା କୌଣସି ବୈଧ nested virtualization କୁ ନଷ୍ଟ କରିଦିଏ — VMs ଭିତରେ VMs ଚାଲିବା। ଏହା ଏକ ଅସ୍ଥାୟୀ ସମାଧାନ, kernel patch ର ବିକଳ୍ପ ନୁହେଁ।

ନିଷ୍କର୍ଷ

Januscape ମନେ ପକାଇଦିଏ ଯେ କ୍ଲାଉଡ୍ କମ୍ପ୍ୟୁଟିଂର ସବୁଠାରୁ ଶକ୍ତିଶାଳୀ କାନ୍ଥ ଏବେ ବି ସଫ୍ଟୱେର୍ ରେ ତିଆରି, ଏବଂ ଷୋହଳ ବର୍ଷ ପୂର୍ବେ ଲେଖାଯାଇଥିବା ସଫ୍ଟୱେର୍ ଗୋଟିଏ ଭୁଲକୁ ସମଗ୍ର ଇଣ୍ଡଷ୍ଟ୍ରିକୁ ବିପଦରେ ପକାଇବା ପାଇଁ ଯଥେଷ୍ଟ ସମୟ ଲୁଚାଇ ରଖିପାରେ। ଖୁସିର ଖବର ହେଉଛି ଯେ ଫିକ୍ସ ପୂର୍ବରୁ ଆସିସାରିଛି ଏବଂ ସମାଧାନ ସହଜ ଅଟେ। କମ୍ପ୍ୟୁଟ୍ ସେୟାର କରୁଥିବା ପ୍ରତ୍ୟେକ ଅପରେଟରଙ୍କ ସାମ୍ନାରେ ଥିବା କାର୍ଯ୍ୟ ସାଧାରଣ କିନ୍ତୁ ସ୍ପଷ୍ଟ: ଆପଣଙ୍କ kernel ଯାଞ୍ଚ କରନ୍ତୁ, ଏହାକୁ ପାଚ୍ କରନ୍ତୁ, ଏବଂ ଯଦି ଆପଣ ଆଜି ପାଚ୍ କରିପାରିବେ ନାହିଁ, ତେବେ ପାଚ୍ ନ କରିବା ପର୍ଯ୍ୟନ୍ତ nested virtualization ବନ୍ଦ କରନ୍ତୁ। ଏକ ସାର୍ବଜନୀନ ପାଚ୍ ଏବଂ ଏକ ସାର୍ବଜନୀନ ହତିଆରସଦୃଶ exploit ମଧ୍ୟରେ ଥିବା ସମୟ ବ୍ୟବଧାନ ଦିନରେ ମାପାଯାଏ, ମାସରେ ନୁହେଁ।

ସୁବିଧାଗୁଡ଼ିକ

• ଫିକ୍ସ ପୂର୍ବରୁ ଉପଲବ୍ଧ ଅଛି। ତ୍ରୁଟି ସାର୍ବଜନୀନ ହେବା ଦିନ ହିଁ Patched stable kernels ରିଲିଜ୍ କରାଯାଇଥିଲା, ତେଣୁ ସମାଧାନ ହେଉଛି ଏକ ନିୟମିତ ଅପଡେଟ୍, କୌଣସି ଗବେଷଣା ପ୍ରକଳ୍ପ ନୁହେଁ।
• ଏକ ସ୍ପଷ୍ଟ, ତୁରନ୍ତ ନିରାକରଣ। nested virtualization ନିଷ୍କ୍ରିୟ କରିବା ଦ୍ୱାରା ଆପଣ ନୂଆ kernel ରେ ରିବୁଟ୍ କରିବା ପୂର୍ବରୁ ମଧ୍ୟ ଆକ୍ରମଣ ପଥ ବନ୍ଦ ହୋଇଯାଏ।
• ସମନ୍ୱିତ ପ୍ରକାଶନ କାର୍ଯ୍ୟ କରିଛି। ଏହି ବଗ୍ Google ର kvmCTF ରିୱାର୍ଡ ପ୍ରୋଗ୍ରାମ୍ ମାଧ୍ୟମରେ ମେଣ୍ଟେନରମାନଙ୍କ ପାଖରେ ପହଞ୍ଚିଥିଲା, ଏବଂ ଏକ ହତିଆରସଦୃଶ exploit ଆସିବା ପୂର୍ବରୁ ପାଚ୍ ପ୍ରଦାନ କରାଯାଇଥିଲା।

ଅସୁବିଧାଗୁଡ଼ିକ

• ଷୋହଳ ବର୍ଷର ନୀରବ ବିପଦ। ପ୍ରକାଶନ ପୂର୍ବରୁ ଏହି ତ୍ରୁଟି ଗୋପନରେ ବ୍ୟବହୃତ ହୋଇନଥିଲା ବୋଲି କେହି ନିଶ୍ଚିତ ଭାବରେ କହିପାରିବେ ନାହିଁ।
• ବିଭିନ୍ନ ଭେଣ୍ଡର ମଧ୍ୟରେ ପ୍ରଭାବ। କାରଣ ଏହା ସେୟାର କରାଯାଇଥିବା shadow-MMU କୋଡ୍ ରେ ଅଛି, ସେଥିପାଇଁ ବ୍ୟବହାର କରିବାକୁ କୌଣସି "ସୁରକ୍ଷିତ" Intel କିମ୍ବା AMD ଚିପ୍ ନାହିଁ।
• ଗୋପନୀୟ ଭାବରେ ଏକ ସମ୍ପୂର୍ଣ୍ଣ-RCE exploit ବିଦ୍ୟମାନ ଅଛି। ସାର୍ବଜନୀନ PoC କେବଳ host କୁ କ୍ରାସ୍ କରାଏ, କିନ୍ତୁ ଗବେଷକ ନିଶ୍ଚିତ କରନ୍ତି ଯେ ଏକ ଅଧିକ ଶକ୍ତିଶାଳୀ, ଅଣ-ରିଲିଜ୍ ହୋଇଥିବା ସଂସ୍କରଣ host code execution ହାସଲ କରେ।

ସାବଧାନତା

ସାର୍ବଜନୀନ proof-of-concept କୁ ବିପଦର ସର୍ବୋଚ୍ଚ ସୀମା ଭାବରେ ଗ୍ରହଣ କରନ୍ତୁ ନାହିଁ। ଏହା କେବଳ host କୁ panic କରାଏ; ପ୍ରକୃତ ବିପଦ ହେଉଛି ଗୋପନୀୟ exploit ଯାହା କୁହାଯାଉଛି ସମ୍ପୂର୍ଣ୍ଣ host execution ହାସଲ କରେ। ଯଦି ଆପଣ multi-tenant ଇନଫ୍ରାଷ୍ଟ୍ରକ୍ଚର ପରିଚାଳନା କରନ୍ତି, ସୁବିଧା ଅପେକ୍ଷା kernel patch କୁ ପ୍ରାଥମିକତା ଦିଅନ୍ତୁ, ଏବଂ ନିଶ୍ଚିତ କରନ୍ତୁ uname -r ସହିତ ଯେ ପ୍ରତ୍ୟେକ host ପ୍ରକୃତରେ ଫିକ୍ସଡ୍ ବିଲ୍ଡରେ ରିବୁଟ୍ ହୋଇଛି — ଏକ patched ପ୍ୟାକେଜ୍ ଯାହା ଏବେ ବି ପୁରୁଣା kernel ଚଲାଉଛି, ତାହା କିଛି ବି ସୁରକ୍ଷା ଦିଏନାହିଁ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନ

ଏହା ମୋର ବ୍ୟକ୍ତିଗତ ଲ୍ୟାପଟପ୍ କିମ୍ବା ଡେସ୍କଟପ୍ କୁ ପ୍ରଭାବିତ କରେ କି? କେବଳ ପରୋକ୍ଷ ଭାବରେ। ଯଦି ଆପଣ nested virtualization ସହିତ ଅବିଶ୍ୱସ୍ତ guest VMs ଚଲାଉନାହାଁନ୍ତି, ତେବେ ଆପଣ ଏହି ଆକ୍ରମଣର ଲକ୍ଷ୍ୟ ନୁହଁନ୍ତି — କିନ୍ତୁ ଆପଣଙ୍କ kernel ପାଚ୍ କରିବା ଏବେ ବି ଏକ ଭଲ ଅଭ୍ୟାସ।

କେବଳ nested virtualization ନିଷ୍କ୍ରିୟ କରିବା ଯଥେଷ୍ଟ କି? ଏହା ଅବିଶ୍ୱସ୍ତ guests ମାନଙ୍କ ପାଇଁ ଜଣାଶୁଣା ଆକ୍ରମଣ ପଥକୁ ହଟାଇଦିଏ, କିନ୍ତୁ ଏହା ଏକ ଅସ୍ଥାୟୀ ସମାଧାନ। ଯେତେ ଶୀଘ୍ର ସମ୍ଭବ kernel patch ପ୍ରୟୋଗ କରନ୍ତୁ ଏବଂ କେବଳ patched hosts ରେ nested virt କୁ ପୁନଃ ସକ୍ଷମ କରନ୍ତୁ।

ମୋର କ୍ଲାଉଡ୍ ପ୍ରୋଭାଇଡର୍ ମୋ ପାଇଁ ଏହାକୁ ଫିକ୍ସ କରିପାରିବେ କି? ପ୍ରମୁଖ ପ୍ରୋଭାଇଡର୍‌ମାନେ ସେମାନଙ୍କ ପକ୍ଷରୁ host hypervisor କୁ ପାଚ୍ କରନ୍ତି; ଆପଣଙ୍କ ନିଜର guest VMs ଦୁର୍ବଳ ଉପାଦାନ ନୁହଁନ୍ତି। ଯଦି ଆପଣ ଅଟନ୍ତି ପ୍ରୋଭାଇଡର୍ — କମ୍ପ୍ୟୁଟ୍ ପୁନଃ ବିକ୍ରି କରୁଛନ୍ତି କିମ୍ବା shared runners ଚଲାଉଛନ୍ତି — ତେବେ ଦାୟିତ୍ୱ ଆପଣଙ୍କର।

ଏହାକୁ "Januscape" କାହିଁକି କୁହାଯାଏ? ଏହି ନାମ ଦୁଇଟି ମୁହଁ ଥିବା ରୋମାନ୍ ଦେବତା Janus କୁ ମନେ ପକାଇଦିଏ — x86 ଦୁନିଆର ଉଭୟ Intel ଏବଂ AMD ଦିଗକୁ ବ୍ୟାପିଥିବା ଏକ ତ୍ରୁଟି ପାଇଁ ଉପଯୁକ୍ତ।

ଟ୍ୟାଗ୍‌ଗୁଡ଼ିକ

security, linux, virtualization, kvm, cve