[kernel] bug#109: kernel] bug#109: iptables causes trap 27
X-PA-RISC Linux-PR-Message: report 109
X-PA-RISC Linux-PR-Package: kernel
Received: via spool by firstname.lastname@example.org id=B109.98767763922886
(code B ref 109); Thu, 19 Apr 2001 11:03:01 GMT
Date: Thu, 19 Apr 2001 11:53:58 +0100
From: Richard Hirst <email@example.com>
To: Grant Grundler <firstname.lastname@example.org>,
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <no.id>; from email@example.com on Thu, Apr 19, 2001 at 04:42:06AM +0000
On Thu, Apr 19, 2001 at 04:42:06AM +0000, firstname.lastname@example.org wrote:
> X-PA-RISC Linux-PR-Message: report 109
> X-PA-RISC Linux-PR-Package: kernel
> X-Loop: email@example.com
> Received: via spool by firstname.lastname@example.org id=B109.98765449418885
> (code B ref 109); Thu, 19 Apr 2001 04:33:01 GMT
> Message-Id: <200104190421.WAA21523@puffin.external.hp.com>
> To: Richard Hirst <email@example.com>
> Cc: firstname.lastname@example.org
> In-Reply-To: Your message of "Wed, 18 Apr 2001 22:41:44 BST."
> Date: Wed, 18 Apr 2001 22:21:37 -0600
> From: Grant Grundler <email@example.com>
> Richard Hirst wrote:
> > > 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...
> > I'd guess gr26 was screwed. Surely the top half should be zero?
> I thought so too. But then thought I have no clue how we copy from
> kernel to user space and have sr1 == sr0. Hopefully jsm or willy
> can comment on this ASAP.
> I haven't traced the syscall path.
> This could be a 32-user/64-kernel issue.
> 0x00011980 would be a valid user app address while 0xe9d4 would not.
Spot on. do_replace() copies a struct ipt_replace from user space and
the tries to use a (32 bit) pointer from that struct as somewhere to
copy the old counter values to. I think this means we need a syscall
wrapper for at least sys_setsockopt, if I've understood how do_replace()
In the meantime, I did this very ugly hack, which should work given
the layout of the struct, and the fact that 32 bit userland adds 4
bytes of padding after the counter anyway. counters is at offset
88, struct size is 96 (which explains why the len check at the
start of do_replace didn't fail).
With this, I could run your firewall script without any obvious problems.
RCS file: /home/cvs/parisc/linux/net/ipv4/netfilter/ip_tables.c,v
retrieving revision 1.3
diff -u -r1.3 ip_tables.c
--- ip_tables.c 2001/01/25 00:03:55 1.3
+++ ip_tables.c 2001/04/19 10:41:17
@@ -1107,8 +1107,13 @@
IPT_ENTRY_ITERATE(oldinfo->entries, oldinfo->size, cleanup_entry,NULL);
/* Silent error: too late now. */
+#if defined(__hppa__) && defined(__LP64__)
+ copy_to_user((void *)((long)tmp.counters >> 32), counters,
+ sizeof(struct ipt_counters) * tmp.num_counters);
sizeof(struct ipt_counters) * tmp.num_counters);