Add kernelCTF CVE-2026-43074_lts#380
Conversation
|
|
||
| void ExploitLayout::load_from_xdk(const char* distro, const char* release) { | ||
| TargetDb kxdb("target_db.kxdb", target_db); | ||
| auto target = kxdb.GetTarget(distro, release); |
There was a problem hiding this comment.
Please check kernelXDK documentation and samples. Please use kxdb.AutoDetectTarget() here.
There was a problem hiding this comment.
Fixed in e44145e: now uses kxdb.AutoDetectTarget() instead of manual distro/release selection.
| " --shell shell mode\n" | ||
| " --image-offset HEX override image offset\n" | ||
| " --nperm-addr HEX override layout nperm address (default: 0x%lx)\n" | ||
| " --xdk-distro NAME Kernel XDK target distro (default: %s)\n" |
There was a problem hiding this comment.
Passing the target distro and release as command-line arguments defeats the framework's built-in fingerprinting capabilities. We don't want manual overrides here. Please review the examples in libxdk/samples and refactor this to rely entirely on the framework's auto-detection.
There was a problem hiding this comment.
Fixed in e44145e: the manual XDK target CLI options were removed.
| TargetDb kxdb("target_db.kxdb", target_db); | ||
| auto target = kxdb.GetTarget(distro, release); | ||
|
|
||
| panic_on_oops = target.GetSymbolOffset("panic_on_oops") + kernel_text_base; |
There was a problem hiding this comment.
The panic_on_oops symbol isn't included in the default kernelXDK database. If your exploit relies on this offset, you will need to extend the extraction logic to include it. Please check the documentation on xdk.dev for how to add custom symbols to the DB generation before querying them here.
Please apply to the other symbols too
There was a problem hiding this comment.
Fixed in e44145e.
Added docs/xdk-db.md describing the DB generation flow and included the DB updates in this commit. The loading path was also refactored to remove the fallback behavior — required layout information is now expected to come from kernelXDK, and missing offsets cause an explicit failure.
There was a problem hiding this comment.
Please have a look at https://xdk.dev/libxdk/how_to_get_started.html#initialize-the-target-database. Effectively you should add symbols for specific target that you run against. But the logic is that later kernelXDK team would add your symbols to default DB as smth available on all targets for all exploits.
If you follow the guidelines, you could skip adding extra docs to docs/xdk-db.md
| state.options.offsets.image_offset, state.options.runtime.nokaslr ? 1 : 0, | ||
| state.options.layout.nperm_addr, state.options.spray.size_kb, | ||
| state.options.spray.slow_nperm, state.options.runtime.use_unmovable_nperm ? 1 : 0, | ||
| state.options.layout.loaded_from_xdk ? 1 : 0); |
There was a problem hiding this comment.
This appears to be a compliance workaround. Toggling a flag just to print a debug statement does not meet the requirement for using the kernelXDK framework.
There was a problem hiding this comment.
You're right. I initially misunderstood how the kernelXDK DB generation worked and assumed all required symbols would be present by default.
Fixed in e44145e: I added DB generation documentation (docs/xdk-db.md), updated the DB, removed the fallback path, and now require all layout information to come directly from kernelXDK.
artmetla
left a comment
artmetla
left a comment
There was a problem hiding this comment.
Please check the comments and improve kernelXDK usage.
|
Hi @artmetla, thanks for the review. We've addressed the requested XDK changes in e44145e. Also noticed CI failing during environment setup before reaching the exploit changes. The failure appears to happen while preparing |
|
Hey @r33s3n6. Thanks for ping, fixed the vuln-verify. Please check my comment on how symbols should be added for specific targets. |
Thanks @artmetla, that clears it up. We had been reading https://xdk.dev/about/kxdb_database.html#configuration-file and initially thought extending |
3 participants
No description provided.