# 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
- `sys/ddb/db_expr.c:216`

## 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.