insn_get_addr_ref(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… insn_get_addr_ref(9) β€” from the Kernel API Manual, bestie πŸŽ€

Okay so picture this: you're deep in the kernel, x86 land, and you've got an instruction sitting there all decoded and cute, and you're like "…and WHERE exactly is this thing pointing??" That's the whole gig. This little icon tells you.


✨ NAME ✨

insn_get_addr_ref β€” Obtain the linear address referred by instruction. That's it, that's the whole vibe. πŸ’–


🌸 SYNOPSIS 🌸

void __user * insn_get_addr_ref (struct insn *insn , struct pt_regs
       *regs );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • insn β€” the Instruction structure, and she is carrying the ModRM byte and the displacement. Everything you need to figure out what she's referencing lives in here. πŸ‘‘
  • regs β€” the Structure with register values as seen when entering kernel mode. Like, the snapshot of the registers from the moment you crossed into the kernel. Don't lose it, it's important. 🫢

πŸ’œ DESCRIPTION πŸ’œ

So what does she actually do? She obtains the linear address referred by the instruction's ModRM, SIB and displacement bytes, and segment base, as applicable. All the applicable pieces, together, one address. Ngl it's a lot of bookkeeping and she ate. πŸ’…

And in protected mode? Segment limits are enforced. Not optional, not a suggestion β€” enforced. ⭐

So on success you get:

  • Linear address referenced by instruction and registers. ✨

And if things go sideways:

  • -1L on error. 😭 That's the whole error report, no cap.

πŸ”₯ SEE ALSO πŸ”₯

The whole fam lives in the kernel file ./arch/x86/lib/insn-eval.c and honestly the friend group is huge:

is_string_insn(9), insn_has_rep_prefix(9), get_seg_reg_override_idx(9), check_seg_overrides(9), resolve_default_seg(9), resolve_seg_reg(9), get_segment_selector(9), get_reg_offset_16(9), get_desc(9), insn_get_seg_base(9), get_seg_limit(9), insn_get_code_seg_params(9), insn_get_modrm_rm_off(9), insn_get_modrm_reg_off(9), insn_get_modrm_reg_ptr(9), get_seg_base_limit(9), get_eff_addr_reg(9), get_eff_addr_modrm(9), get_eff_addr_modrm_16(9), get_eff_addr_sib(9), get_addr_ref_16(9), get_addr_ref_32(9), get_addr_ref_64(9), insn_fetch_from_user(9), insn_fetch_from_user_inatomic(9), insn_decode_from_regs(9), insn_decode_mmio(9)

iykyk πŸ’€πŸ™ˆ


🧚 Real talk: if you're calling this, make sure insn actually has its ModRM byte and displacement sitting in it, and that regs is the register state from kernel entry. That's literally the contract. πŸ’–

Later, bestie!! This one's from ./arch/x86/lib, dated October 2026, and it will absolutely see you again when you need to know where an instruction is pointing. Mwah πŸ’‹πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from