lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 2 Jul 2014 10:20:39 +0300 From: Dan Aloni <dan@...nelim.com> To: Sasha Levin <sasha.levin@...cle.com> Cc: Pablo Neira Ayuso <pablo@...filter.org>, Patrick McHardy <kaber@...sh.net>, kadlec@...ckhole.kfki.hu, "David S. Miller" <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Dave Jones <davej@...hat.com>, netfilter-devel@...r.kernel.org, coreteam@...filter.org Subject: Re: net: pretty odd panic in netfilter 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 netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists