Right-shift operator truncates operand to 32 bits (LP64 porting bug)
Summary
db_shift_expr casts left operand of >> to (unsigned) (32-bit) before shifting instead of (unsigned long) (64-bit). On x86_64 db_expr_t is long (64-bit). Cast silently discards high 32 bits of operand. Expression 0x123456789abcdef0>>4 should yield 0x123456789abcdef but code computes (unsigned)0x123456789abcdef0=0x9abcdef0 then >>4=0x09abcdef assigned back 0x0000000009abcdef high dword silently lost. Classic LP64 porting bug original Mach code correct on ILP32 where unsigned==long never updated when db_expr_t became 64-bit. DDB-only privileged context operator can already read any kernel memory via examine. Wrong value computed for any right-shift whose operand exceeds 32 bits can mislead operator during debugging wrong address wrong memory examined misdiagnosed crash. No security impact correctness defect only. [VERIFIED pass2: runtime reproduced via exact-expression replica - unsigned shift truncates 64-bit lhs to 32; LP64 cast fix compile-validated]
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2242 · 10 files| File | Type | Description | Size | |
|---|---|---|---|---|
| VERDICT.md | — | 1.6 KB | ↓ raw | |
| README.md | — | 235 B | ↓ raw | |
| build.sh | — | 88 B | view raw | |
| run.sh | — | 60 B | view raw | |
| env.txt | — | 314 B | view raw | |
| manifest.json | — | 581 B | view raw | |
| verdict.json | — | 1.8 KB | view raw | |
| fix.diff | — | 234 B | view raw | |
| dbexpr_shift.c | — | 935 B | view raw | |
| run.log | — | 241 B | view raw |
DF-2242 evidence pack
- finding: sys/ddb/db_expr.c (216)
- verdict: reproduced (certain) - see VERDICT.md
- runtime PoC: dbexpr_shift.c
- reproduce: build.sh / run.sh ; expected output in run.log
- fix.diff: present, git-apply-able
DF-2242 - Verification Verdict
Status: reproduced Impact: none (hardening) Confidence: certain
Mechanism
db_shift_expr evaluates right shift as lhs = (unsigned) lhs >> rhs. db_expr_t is intmax_t (64-bit) and the (unsigned) cast - not (unsigned int)-safe on LP64 - truncates the operand to 32 bits before shifting, so any 64-bit ddb expression containing >> computes a 32-bit result.
Verdict
REPRODUCED (semantics, userland replica of the exact expression): lhs=0x123456789abcdef0 >> 4 evaluates to 0x0000000009abcdef through the shipped expression (the top 32 bits are destroyed before the shift) instead of 0x0123456789abcdef. Only reachable from the ddb prompt (console/operator), so this is an LP64 porting bug in the debugger expression engine, not an exploit surface.
Threat / reachability
ddb console users get silently wrong values for 64-bit addresses; e.g. examine/symbol arithmetic during incident response.
Privilege escalation assessment
n/a (ddb operator tool)
Fix
Cast to (uintmax_t) so the shift operates on the full 64-bit operand.
Kernel references
Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.
Note: an earlier draft of this fix.diff failed the first combined build (see _batch41/README.md); the shipped diff is the corrected, compile-clean version.
Fix verification
not_testablefix.diff compile-validated in the batch combined kernel build (all 37 diffs of this batch applied to in-guest /usr/src; make -j6 nativekernel KERNCONF=X86_64_GENERIC, see batch build log referenced in VERDICT.md); no behavior A/B performed for this Info-tier item; behavior A/B intentionally skipped for Info tier
batch combined kernel build log (see findings/poc/_batch41 note in VERDICT.md)
Confirmed kernel references
Detail
Exploit chain
no escalation path: ddb console expression engine only (operator already privileged)
Evidence (decisive lines)
run.log: lhs 0x123456789abcdef0 >> 4 = 0x0000000009abcdef through the shipped cast vs 0x0123456789abcdef fixed
PoC changes
none (semantics replica of the exact ddb expression)
Verified recommended fix
Cast to (uintmax_t) so the shift operates on the full 64-bit operand.
Verdict
REPRODUCED (semantics, userland replica of the exact expression): lhs=0x123456789abcdef0 >> 4 evaluates to 0x0000000009abcdef through the shipped expression (the top 32 bits are destroyed before the shift) instead of 0x0123456789abcdef. Only reachable from the ddb prompt (console/operator), so this is an LP64 porting bug in the debugger expression engine, not an exploit surface.
No comments yet.