This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 76465 - cipcb driver causes kernel oops when scanned using nmap
cipcb driver causes kernel oops when scanned using nmap
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-21 23:48 EDT by Herrick, Andrew
Modified: 2007-04-18 12:47 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-03 12:39:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
syslog output for both machines. (5.04 KB, text/plain)
2002-10-21 23:58 EDT, Herrick, Andrew
no flags Details
Test patch to attempt to trap bug (609 bytes, patch)
2002-10-22 13:27 EDT, Jeff Garzik
no flags Details | Diff

  None (edit)
Description Herrick, Andrew 2002-10-21 23:48:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
I have a cipe tunnel between two networks. Network A has a Redhat 7.3 router,
Network B has a Redhat 8.0 router. Both machines are up to date on all errata as
of 2002-10-21. Both machines are dual processor Pentium 2's running SMP kernels.
When I scan Network B's router using nmap's UDP scan feature it causes a kernel
oops, but does not entirely crash the machine. The nmap scan options are as follows:

nmap -sU -p 28007-28007 -P0 <hostname>

28007 is the port cipe is listening to.

It may be of interest to note that the host I am scanning from is NAT'ed to the
same IP that one end of the tunnel terminates.

I will attach the oops output from the kernel log to this bug.

If you need any further information, I am happy to provide it.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. (Router for Network B) ifup cipcb0
2. (Any host) nmap -sU -p 28007-28007 -P0 <routerbip>
3. Watch as the oops flies :)
	

Actual Results:  cipe produces an oops and all cipe tunnels become unusable.

Expected Results:  cipe should either produce a warning or silently discard any
errant packets.

Additional info:

i have 'options cipcb cipe_debug=0' in /etc/modules.conf
Comment 1 Herrick, Andrew 2002-10-21 23:49:50 EDT
Here is the oops info that was generated by Network B's router:

Oct 21 22:12:43 gw kernel: Unable to handle kernel paging request at virtual
address c4000000
Oct 21 22:12:43 gw kernel:  printing eip:
Oct 21 22:12:43 gw kernel: c49134d0
Oct 21 22:12:43 gw kernel: *pde = 00000000
Oct 21 22:12:43 gw kernel: Oops: 0000
Oct 21 22:12:43 gw kernel: cipcb natsemi pcnet32 mii ipt_REJECT ipt_state
ipt_TOS ipt_LOG ipt_limit iptab
Oct 21 22:12:43 gw kernel: CPU:    1
Oct 21 22:12:43 gw kernel: EIP:    0010:[<c49134d0>]    Not tainted
Oct 21 22:12:43 gw kernel: EFLAGS: 00010207
Oct 21 22:12:43 gw kernel:
Oct 21 22:12:43 gw kernel: EIP is at crc32 [cipcb] 0x20 (2.4.18-17.8.0smp)
Oct 21 22:12:43 gw kernel: eax: 000000c7   ebx: c4917260   ecx: 006a0538   edx:
05d1d13c
Oct 21 22:12:43 gw kernel: esi: fffffff4   edi: c395fac8   ebp: c22edde0   esp:
c22edd8c
Oct 21 22:12:43 gw kernel: ds: 0018   es: 0018   ss: 0018
Oct 21 22:12:43 gw kernel: Process ciped-cb (pid: 7774, stackpage=c22ed000)
Oct 21 22:12:43 gw kernel: Stack: c395fac0 c395fac8 c1eac000 c49133ff c395fac8
fffffff4 c1eac01c 00000008
Oct 21 22:12:43 gw kernel:        c1263430 000091ac c3bf9032 c1ddc960 c3b2e300
c491180e c1eac000 c395fac8
Oct 21 22:12:43 gw kernel:        c22edde0 00000008 c2631580 c22ede14 054cbd41
fffffff8 c3b2e300 c1eac000
Oct 21 22:12:43 gw kernel: Call Trace: [<c49133ff>] cipe_decrypt [cipcb] 0x6f
(0xc22edd98))
Oct 21 22:12:43 gw kernel: [<c491180e>] cipe_decrypt_skb [cipcb] 0x1ee (0xc22eddc0))
Oct 21 22:12:43 gw kernel: [<c4911cfc>] cipe_recvmsg [cipcb] 0xcc (0xc22eddf4))
Oct 21 22:12:43 gw kernel: [<c024764e>] inet_recvmsg [kernel] 0x4e (0xc22ede28))
Oct 21 22:12:43 gw kernel: [<c01fe528>] sock_recvmsg [kernel] 0x58 (0xc22ede4c))
Oct 21 22:12:44 gw kernel: [<c01fe25c>] sockfd_lookup [kernel] 0x1c (0xc22ede80))
Oct 21 22:12:44 gw kernel: [<c01ff772>] sys_recvfrom [kernel] 0xb2 (0xc22ede94))
Oct 21 22:12:44 gw kernel: [<c0208120>] dev_ifsioc [kernel] 0x3d0 (0xc22edf20))
Oct 21 22:12:44 gw kernel: [<c01ff817>] sys_recv [kernel] 0x37 (0xc22edf64))
Oct 21 22:12:44 gw kernel: [<c01fff98>] sys_socketcall [kernel] 0x168 (0xc22edf80))
Oct 21 22:12:44 gw kernel: [<c015bdd1>] sys_ioctl [kernel] 0xc1 (0xc22edf94))
Oct 21 22:12:44 gw kernel: [<c0109447>] system_call [kernel] 0x33 (0xc22edfc0))
Oct 21 22:12:44 gw kernel:
Oct 21 22:12:44 gw kernel:
Oct 21 22:12:44 gw kernel: Code: 0f b6 04 39 41 30 d0 c1 ea 08 0f b6 c0 33 14 83
39 f1 72 ec
Comment 2 Herrick, Andrew 2002-10-21 23:54:27 EDT
This also works against the router running Redhat 7.3. I will attach the oops
output from that machine as well.
Comment 3 Herrick, Andrew 2002-10-21 23:58:30 EDT
Created attachment 81484 [details]
syslog output for both machines.
Comment 4 Jeff Garzik 2002-10-22 13:27:29 EDT
Created attachment 81584 [details]
Test patch to attempt to trap bug
Comment 5 Jeff Garzik 2002-10-22 13:28:34 EDT
Can you try to reproduce with the above kernel patch, and see if that prints
'CIPE BUG' (and other info) to the kernel log / dmesg?
Comment 6 Jeff Garzik 2002-10-22 13:40:46 EDT
Also, can you try CIPE 1.5.4?
http://sites.inka.de/sites/bigred/sw/cipe-1.5.4.tar.gz

It definitely seems to have useful changes in the area of this oops.
Comment 7 Herrick, Andrew 2002-10-22 21:21:34 EDT
On my uniprocessor test system the patch doesn't produce either an oops or a
CIPE_BUG message. I'm going to push a kernel with this patch out to one of my
production systems (keep your fingers crossed) and see what happens...
Comment 8 Herrick, Andrew 2002-10-23 02:24:23 EDT
Ok, I tried the patch on a production system. Redhat 8.0 latest kernel compiled
into an RPM with your patch added. Sending the same probe doesn't produce a
kernel oops. However, it doesn't emit the CIPE_BUG message either. Strangely,
the only diagnostic information I get is from dmesg which emits '<3>' when the
packet hits and then '<7>' when I shut down the cipe link.

I will test cipe 1.5.4, but I am hesitant to use it permanently. (I would rather
use your vendor supplied binaries when possible, you have a quality assurance
dept., I only have a few systems to test with. :) Any chance you could include
cipe 1.5.4 in a future kernel errata?
Comment 9 Mike McLean 2003-01-02 12:39:13 EST
This bug has been inappropriately marked MODIFIED. Please review the bug life
cycle information at 
http://bugzilla.redhat.com/bugzilla/bug_status.cgi

Changing bug status to ASSIGNED.
Comment 10 Jeff Garzik 2003-01-31 12:04:33 EST
Can you confirm this bug is fixed in the most recent Red Hat errata kernel, for
8.0?  (or in the phoebe beta kernel, or in the Red Hat rawhide kernel...)
Comment 11 Herrick, Andrew 2003-01-31 18:34:56 EST
Tested on latest errata kernel 2.4.18-19.8.0 and it appears to be fixed. No
kernel oops. Subsequent scans continue to show port in 'open' status. Packets
continue to flow over the connection. Looks good! Thanks.

Note You need to log in before you can comment on or make changes to this bug.