[kernel] bug#109: iptables causes trap 27
None
X-PA-RISC Linux-PR-Message: report 109
X-PA-RISC Linux-PR-Package: kernel
X-Loop: daniel_frazier@hp.com
Received: via spool by bugs@bugs.parisc-linux.org id=B.98762688814379
(code B ref -1); Wed, 18 Apr 2001 21:03:01 GMT
Message-Id: <200104182041.OAA20296@puffin.external.hp.com>
To: submit@bugs.parisc-linux.org
Date: Wed, 18 Apr 2001 14:41:27 -0600
From: Grant Grundler <grundler@puffin.external.hp.com>
Package: kernel
Version: 20010418
Severity: grave
Summary
Tried to run iptables on my A500 from /etc/init.d/firewall script.
Resulted in a "Segementation fault" (trap 27 on console output).
Kernel spewed register state at that point and locked up.
I'll submit the firewall script and .config I was using in seperate e-mails.
Notes of what I've looked at so far are appended. Out of time at the
moment to track this further.
grant
a500:/etc/init.d# ./firewall start
Starting firewall (iptables):firewall INPUT -i eth0 -j LOG -s localhost
firewall INPUT -i eth0 -j DROP -s localhost
firewall INPUT -i eth0 -j LOG -s a500
firewall INPUT -i eth0 -j DROP -s a500
firewall INPUT -i eth1 -j ACCEPT
firewall INPUT -i eth2 -j ACCEPT
firewall INPUT -i eth3 -j ACCEPT
firewall INPUT -s localhost -j ACCEPT
firewall INPUT -s a500 -j ACCEPT
firewall INPUT -s 192.168.0.20 -j ACCEPT
firewall INPUT -j ACCEPT -p tcp --syn -d 0/0 --dport 22
firewall INPUT -j ACCEPT -p tcp --syn -d 0/0 --dport http
firewall INPUT -j ACCEPT -p tcp --syn -d 0/0 --dport smtp
firewall INPUT -j ACCEPT -p tcp --syn -d 0/0 --dport ident
./firewall: line 3: 724 Segmentation fault iptables -A $*
firewall INPUT -j ACCEPT -p tcp --syn -d 0/0 --dport ftp
iptables[724]: Protection Id Trap 27
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000011000000000000001111
r0-3 0000000000000000 0000000000000040 00000000102a316c 000000000008da58
r4-7 0000000010373600 0000000000000070 000000000008d9e8 000000000008d000
r8-11 0000000010373600 0000000000000a58 0000000010373600 000000000008f000
r12-15 0000000000000000 00000000ffffffff 00000000000aee70 0000000000000000
r16-19 0000000000000000 0000000000007514 0000000000005000 000000000000003b
r20-23 0000000000000020 000000000000001f 0000000000000001 0000000000098000
r24-27 00000000000000ff 000000000008f001 000119800000e9d4 0000000010373600
r28-31 0000000000000013 00000000fcae8e30 00000000fcae9180 0000000000000000
sr0-3 0000000000000180 0000000000000180 0000000000000000 0000000000000180
sr4-7 0000000000000000 0000000000000000 0000000000000000 0000000000000000
IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000102c43a8 00000000102c43a0
IIR: 0f415222 ISR: 0000000000011980 IOR: 000000000000e9d4
ORIG_R28: 0000000010150e14
IAOQ 0x102c43a8 $lctu_loop+8
GR02 0x102a316c do_replace+51c
No stack trace *sigh*
lctu_loop seems related to copy_to_user
<willy> ggg: no... someone called copy_to_user with an invalid address to
copy _from_, i think.
net/ipv4/netfilter/ip_tables.c:
static int
do_replace(void *user, unsigned int len)
{
...
struct ipt_replace tmp;
struct ipt_counters *counters;
...
if (copy_from_user(&tmp, user, sizeof(tmp)) != 0)
return -EFAULT;
...
counters = vmalloc(tmp.num_counters * sizeof(struct ipt_counters));
if (!counters) {
ret = -ENOMEM;
goto free_newinfo;
}
memset(counters, 0, tmp.num_counters * sizeof(struct ipt_counters));
...
/* Get the old counters. */
get_counters(oldinfo, counters);
...
copy_to_user(tmp.counters, counters,
sizeof(struct ipt_counters) * tmp.num_counters);
...
}
102a3140: 37 dd 3f e1 ldo -10(sp),ret1
102a3144: eb 53 ad c9 b,l 10149830 <vfree>,%r2
102a3148: 08 07 02 5a copy r7,r26
102a314c: 4b d8 3d c9 ldw -11c(sp),r24
102a314c: 4b d8 3d c9 ldw -11c(sp),r24
102a3150: 37 dd 3f e1 ldo -10(sp),ret1
102a3154: 53 da 3d d1 ldd -118(sp),r26
102a3158: 08 08 02 5b copy r8,dp
102a315c: db 18 0b e0 extrd,u r24,63,32,r24
102a3160: 08 0b 02 59 copy r11,r25
102a3164: e8 10 a4 2c call 102c4380 <lcopy_to_user>
102a3168: f3 18 10 84 depd,z r24,59,60,r24
00000000102c4380 <lcopy_to_user>:
102c4380: 87 00 20 4a cmpib,=,n 0,r24,102c43ac <$lctu_done>
102c4384: 08 1e 02 41 copy sp,r1
102c4388: f4 20 04 12 depdi 0,63,14,r1
102c438c: 48 36 00 28 ldw 14(r1),r22
102c4390: 00 00 c4 a1 mfsp sr3,r1
102c4394: 08 16 32 40 or,<> r22,r0,r0
102c4398: 08 00 02 41 copy r0,r1
102c439c: 00 01 58 20 mtsp r1,sr1
00000000102c43a0 <$lctu_loop>:
102c43a0: 0f 22 10 21 ldb,ma 1(sr0,r25),r1
102c43a4: af 1f 3f ed addib,<> -1,r24,102c43a0 <$lctu_loop>
102c43a8: 0f 41 52 22 stb,ma r1,1(sr1,r26) *** TRAP27 ***
00000000102c43ac <$lctu_done>:
102c43ac: e8 40 c0 00 bv r0(rp)
102c43b0: 08 18 02 5c copy r24,ret0
102c43b4: e8 1f 1f e5 b,l 102c43ac <$lctu_done>,r0
102c43b8: 37 18 00 02 ldo 1(r24),r24
GR24 00000000000000ff
GR25 000000000008f001
GR26 000119800000e9d4
SR1 0000000000000180 (SR0 is the same)
Looks like we tried to copyout the counters info but went past the
end of the page/space allocated by iptables. Not sure about this
conclusion though...