{"id":24735,"date":"2026-09-16T20:32:42","date_gmt":"2026-09-16T12:32:42","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-90047"},"modified":"2026-09-16T20:32:42","modified_gmt":"2026-09-16T12:32:42","slug":"cve-2026-90047","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-90047","title":{"rendered":"CVE-2026-90047 &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\ndrm\/xe: Don&#8217;t hand ou"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>drm\/xe: Don&#8217;t hand out the flat CCS storage as usable VRAM<\/p>\n<p>get_flat_ccs_offset() reads the base of the flat CCS storage from the<br \/>\nhardware, scales it by the number of enabled L3 nodes, and rounds the<br \/>\nresult up to 128K.  Everything below that offset is then handed to the<br \/>\nVRAM allocator as usable memory.<\/p>\n<p>Rounding a limit that means &#8220;usable memory ends here&#8221; upwards publishes<br \/>\nwhatever lies between the real base and the rounded one as free memory,<br \/>\nand that memory belongs to the compression hardware.  The scaled value<br \/>\nhas no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it<br \/>\nis not:<\/p>\n<p>\tflat CCS base: raw 0x3fafff800, rounded 0x3fb000000<\/p>\n<p>so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator&#8217;s<br \/>\npool.  Whatever is allocated there gets that tail overwritten by the<br \/>\ncompression hardware, which needs no page-table entry, no buffer object<br \/>\nand no GPU submission to do it, and does it before userspace exists.<\/p>\n<p>On this machine a Mesa VM&#8217;s level-3 page table landed on that page on<br \/>\nevery cold boot.  It lost the entry covering the compositor&#8217;s<br \/>\nbatch-buffer heap, so the compositor&#8217;s first submission faulted fetching<br \/>\nits batch and gdm restarted it forever: a black screen on an otherwise<br \/>\nworking machine.  Restarting gdm cleared it because the next VM&#8217;s page<br \/>\ntables were allocated somewhere else.<\/p>\n<p>Round down instead, to the page size the allocator works in.  On this<br \/>\nmachine that excludes exactly one page.<\/p>\n<p>Reading the reserved page afterwards shows what had been writing it:<\/p>\n<p>\t[369] 0xcccc000000000000<br \/>\n\t[371] 0xcc77000000000000<br \/>\n\t[373] 0xcccc000000000000<br \/>\n\t[375] 0xcc77000000000000<\/p>\n<p>compression metadata, two bytes per sixteen, sitting where the driver<br \/>\nused to hand out memory.<\/p>\n<p>The assertion that should have caught this compares the offset against<br \/>\nGSMBASE &#8211; ccs_size for equality.  That value is 128K aligned, so it<br \/>\nagrees with the rounded-up offset precisely when the base is not<br \/>\naligned &#8211; the check cannot fail in the case it exists to catch, and is<br \/>\ncompiled out unless CONFIG_DRM_XE_DEBUG is set.  Replace it with one<br \/>\nthat can fail: CCS storage must not run into GSM.<\/p>\n<p>[ And this was a debug session from hell, enormously helped by an AI<br \/>\n  doing much of the grunt-work.<\/p>\n<p>  I&#8217;d like to call it my tireless helper, but the AI several times<br \/>\n  stated flat out that this was impossible and unsolvable and that we<br \/>\n  should just write a report about it.<\/p>\n<p>  I suspect those things have been trained by people who may not be<br \/>\n  quite as stubborn as I am.<\/p>\n<p>  But while the AI was ready to give up several times, it did keep<br \/>\n  adding debug code and analyzing it faithfully when I pushed. So credit<br \/>\n  where credit is due and I let the AI write the commit message above.<\/p>\n<p>  This is basically a one-liner fixing a bogus &#8220;round_up()&#8221; to a<br \/>\n  &#8220;round_down()&#8221;, but there were 24 patches adding more and more debug<br \/>\n  information to this, and 18 kernel boot to finally narrow it down to<br \/>\n  this.   &#8211; Linus ]<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>drm\/xe: Don&#8217;t hand out the flat CCS storage as usable VRAM<\/p>\n<p>get_flat_ccs_offset() reads the base of the flat CCS storage from the<br \/>\nh<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-24735","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/24735","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=24735"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=24735"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=24735"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}