On Tue, Jul 01, 2014 at 11:24:17PM -0400, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on a pretty odd corruption(?) in the code - a pretty odd
> one.
>
> Here's the issue I've hit:
>
> [ 3640.805823] BUG: unable to handle kernel paging request at ffffffffffffff84
>[..]
> [ 3640.840752] Code: 4c 89 65 e8 49 89 cc 0f 97 c1 83 fa 01 0f 95 c0 48 89 5d e0 31 db 83 fa 04 4c 89 6d f0 0f 95 c3 4c 89 75 f8 21 55 55 fb 01 48 19 <d2> 48 83 e2 f0 48 83 c2 20 48 89 d0 48 83 f0 30 84 c9 48 0f 45
> [ 3640.840752] RIP nf_nat_packet (net/netfilter/nf_nat_core.c:482)
> [ 3640.840752] RSP <ffff88014608b958>
> [ 3640.840752] CR2: ffffffffffffff84
>
> Two odd things here:
>
> 1. The code section seems to point mid-instruction:
>
> 19dc: 0f 95 c3 setne %bl
> 19df: 4c 89 75 f8 mov %r14,-0x8(%rbp)
> 19e3: 21 c3 and %eax,%ebx
> 19e5: 83 fb 01 cmp $0x1,%ebx
> 19e8: 48 19 d2 sbb %rdx,%rdx <=== The end of this (0xd2)
> 19eb: 48 83 e2 f0 and $0xfffffffffffffff0,%rdx
> 19ef: 48 83 c2 20 add $0x20,%rdx
> 19f3: 48 89 d0 mov %rdx,%rax
> 19f6: 48 83 f0 30 xor $0x30,%rax
>
> 2. There isn't anything in that area that dereferences memory:
>
> enum nf_nat_manip_type mtype = HOOK2MANIP(hooknum);
>
> if (mtype == NF_NAT_MANIP_SRC)
> statusbit = IPS_SRC_NAT;
> else
> statusbit = IPS_DST_NAT;
Hi Sasha,
The fault registers are consistent with the 'rorb %cl,-0x7d(%rax)' starting
at the place where you have 0xd2. But the problem started earlier:
"75 f8 21 55 55 fb 01 48 19 <d2> 48 83 e2 f0"
What should have been according to objdump:
"75 f8 21 c3 83 fb 01 48 19 <d2> 48 83 e2 f0"
^^^^^
These instructions should not have been modified, even by relocation.
So we only need to figure out what overwrote with '0x5555'.
--
Dan Aloni
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
