Description of problem: System halt occured: Apr 10 16:01:01 amicusws02 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 Apr 10 16:01:01 amicusws02 kernel: printing eip: Apr 10 16:01:01 amicusws02 kernel: f8915ea4 Apr 10 16:01:01 amicusws02 kernel: *pde = 17f85001 Apr 10 16:01:01 amicusws02 kernel: Oops: 0000 [#1] Apr 10 16:01:01 amicusws02 kernel: SMP Apr 10 16:01:01 amicusws02 kernel: Modules linked in: iptable_filter ip_tables i2c_dev i2c_core sunrpc dm_mirror dm_mod 3c59x ext3 jbd Apr 10 16:01:01 amicusws02 kernel: CPU: 0 Apr 10 16:01:01 amicusws02 kernel: EIP: 0060:[<f8915ea4>] Not tainted VLI Apr 10 16:01:01 amicusws02 kernel: EFLAGS: 00010246 (2.6.9-11.ELsmp) Apr 10 16:01:01 amicusws02 kernel: EIP is at copy_entries_to_user+0x22e/0x2ab [ip_tables] Apr 10 16:01:01 amicusws02 kernel: eax: 00000000 ebx: 08e52498 ecx: ffffffff edx: 00000070 Apr 10 16:01:01 amicusws02 kernel: esi: 00000008 edi: 00000008 ebp: 08e524aa esp: d7f77c60 Apr 10 16:01:01 amicusws02 kernel: ds: 007b es: 007b ss: 0068 Apr 10 16:01:01 amicusws02 kernel: Process iptables (pid: 29040, threadinfo=d7f77000 task=f558d810) Apr 10 16:01:01 amicusws02 kernel: Stack: f8828060 d7f77c6c 00000070 00000000 f8828000 f8927414 00000394 08e520a4 Apr 10 16:01:01 amicusws02 kernel: f882c7e0 00000444 00000444 08e52080 d7f77cb8 08e52080 f8915f5f 00000000 Apr 10 16:01:01 amicusws02 kernel: 00000041 c033e804 f89168b0 00000000 d7f77000 00000000 746c6966 00007265 Apr 10 16:01:01 amicusws02 kernel: Call Trace: Apr 10 16:01:01 amicusws02 kernel: [<f8915f5f>] get_entries+0x3e/0x63 [ip_tables] Apr 10 16:01:01 amicusws02 kernel: [<f89168b0>] do_ipt_get_ctl+0x206/0x225 [ip_tables] Apr 10 16:01:01 amicusws02 kernel: [<c027ca1c>] nf_sockopt+0x93/0x131 Apr 10 16:01:01 amicusws02 kernel: [<c027cadf>] nf_getsockopt+0xf/0x13 Apr 10 16:01:01 amicusws02 kernel: [<c0290893>] ip_getsockopt+0x5ea/0x7db Apr 10 16:01:01 amicusws02 kernel: [<c019e4da>] avc_insert+0x115/0x11f Apr 10 16:01:01 amicusws02 kernel: [<c019f364>] avc_has_perm_noaudit+0x8d/0xda Apr 10 16:01:01 amicusws02 kernel: [<c013f7c4>] buffered_rmqueue+0x17d/0x1a5 Apr 10 16:01:01 amicusws02 kernel: [<c0149591>] do_anonymous_page+0x1b9/0x1cb Apr 10 16:01:01 amicusws02 kernel: [<c014960c>] do_no_page+0x69/0x2d3 Apr 10 16:01:01 amicusws02 kernel: [<c01499ed>] handle_mm_fault+0xbd/0x175 Apr 10 16:01:01 amicusws02 kernel: [<c011a65b>] do_page_fault+0x1ae/0x5b6 Apr 10 16:01:01 amicusws02 kernel: [<c019f33e>] avc_has_perm_noaudit+0x67/0xda Apr 10 16:01:01 amicusws02 kernel: [<c01b6998>] rb_insert_color+0x58/0xc1 Apr 10 16:01:01 amicusws02 kernel: [<c014a6d1>] __vma_link+0x59/0x66 Apr 10 16:01:01 amicusws02 kernel: [<c026ed4c>] sock_common_getsockopt+0x15/0x19 Apr 10 16:01:01 amicusws02 kernel: [<c026ce30>] sys_getsockopt+0x66/0x7d Apr 10 16:01:01 amicusws02 kernel: [<c026d455>] sys_socketcall+0x1b1/0x1dd Apr 10 16:01:01 amicusws02 kernel: [<c02c7377>] syscall_call+0x7/0xb Apr 10 16:01:01 amicusws02 kernel: Code: 82 70 ff ff ff 8b 44 24 14 8b 4c 24 14 0f b7 50 58 8b 44 24 1c 03 44 24 18 8b 74 11 04 83 c9 ff 8d 6c 10 02 83 c6 08 31 c0 89 f7 <f2> ae f7 d1 49 ba 13 02 00 00 b8 19 76 91 f8 8d 59 01 31 c9 e8 Apr 10 16:01:01 amicusws02 kernel: <0>Fatal exception: panic in 5 seconds Version-Release number of selected component (if applicable): $ uname -a Linux amicusws02 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT 2005 i686 athlon i386 GNU/Linux $ rpm -q kernel kernel-2.6.9-11.EL How reproducible: I don't know Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: This happens when /etc/cron.hourly/portflush executed, but not every time... $ cat /etc/cron.hourly/portflush #!/bin/sh source /etc/sysconfig/portsentry # This will flush the PORTSEN rules from your firewall tool (ipchains or # iptables) every hour if CLEAR_CHAIN is set to "1" in the # /etc/sysconfig/portsentry file if [ "$CLEAR_CHAIN" = "1" ] then $IPTOOL -F $PORTSENTRY_CHAIN rm -f /var/log/portsentry/*blocked* fi exit $ cat /etc/sysconfig/portsentry IPTOOL=iptables PORTSENTRY_CHAIN=PORTSEN CLEAR_CHAIN=1 MAIL_ME=1
This is no iptables user land problem. Assigning to kernel.
We were never able to reproduce this, closing due to inactivity.