Bug 174763 - Unable to handle kernel NULL pointer dereference at virtual address 00000018 in kernel 2.6.14-1.1644_FC4
Unable to handle kernel NULL pointer dereference at virtual address 00000018 ...
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-12-01 18:11 EST by Tore H. Larsen
Modified: 2015-01-04 17:23 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-06 18:16:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tore H. Larsen 2005-12-01 18:11:13 EST
Description of problem: 

Kernel crash sometimes when using bluetooth comm rfcomm0

[root@localhost ~]# hcitool info 00:15:XX:YY:ZZ:PP
Requesting information ...
        BD Address:  00:15:XX:YY:ZZ:PP
        Device Name: Nokia N70
        LMP Version: 2.0 (0x3) LMP Subversion: 0x6cc
        Manufacturer: Cambridge Silicon Radio (10)
        Features: 0xbf 0xee 0x0f 0x46 0x98 0x19 0x00 0x00
                <3-slot packets> <5-slot packets> <encryption> <slot offset>
                <timing accuracy> <role switch> <sniff mode> <RSSI>
                <channel quality> <SCO link> <HV3 packets> <u-law log>
                <A-law log> <CVSD> <paging scheme> <power control>
                <transparent SCO> <EDR ACL 2 Mbps> <EDR ACL 3 Mbps>
                <inquiry with RSSI> <AFH cap. slave> <AFH class. slave>
                <3-slot EDR ACL> <5-slot EDR ACL> <AFH cap. master>
                <AFH class. master>

When using kppp and dialing my ISP machine once crashed and once hung with the
below trace in dmesg

Unable to handle kernel NULL pointer dereference at virtual address 00000018
 printing eip:
*pde = 0dc33067
Oops: 0000 [#1]
Modules linked in: sgil1(U) cisco_ipsec(U) parport_pc lp parport irnet
ppp_generic slhc irtty_sir sir_dev ircomm_tty ircomm irda crc_ccitt autofs4
rfcomm l2cap sunrpc ide_cs pcmcia ipt_REJECT ipt_state ip_conntrack nfnetlink
iptable_filter ip_tables nls_utf8 ntfs(U) ext3 jbd nls_iso8859_1 vfat fat dm_mod
video button battery ac hci_usb bluetooth ipv6 yenta_socket rsrc_nonstatic
pcmcia_core uhci_hcd ehci_hcd snd_intel8x0m snd_intel8x0 snd_ac97_codec
snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc pegasus
mii ipw2200 ieee80211 ieee80211_crypt tg3 joydev xfs exportfs
CPU:    0
EIP:    0060:[<f0c1cc94>]    Tainted: P      VLI
EFLAGS: 00010282   (2.6.14-1.1644_FC4)
EIP is at rfcomm_send_rpn+0xa/0xb9 [rfcomm]
eax: 00000000   ebx: 00000003   ecx: 00000006   edx: 00000001
esi: 00000003   edi: 00000013   ebp: 00000003   esp: d0a8fe58
ds: 007b   es: 007b   ss: 0068
Process kppp (pid: 4790, threadinfo=d0a8f000 task=d8d1d030)
Stack: badc0ded d0a8fe8c d0a8ff0c 00000000 ddd1f4c0 00000003 00000003 f0c2074a
       00000003 00000003 00000000 00000000 00000000 00000011 00000013 00000001
       00000030 00002580 00070800 00000002 d0a8fe00 d0a8fed0 d0a8fee8 00000246
Call Trace:
 [<f0c2074a>] rfcomm_tty_set_termios+0x1ac/0x222 [rfcomm]
 [<c0219ae0>] change_termios+0xd2/0x1c1
 [<c030cb7e>] _spin_lock_irqsave+0x9/0xd
 [<c0219c77>] set_termios+0xa8/0x107
 [<c0219df4>] n_tty_ioctl+0x0/0x34a
 [<c0216279>] tty_ioctl+0x16d/0x3eb
 [<c021610c>] tty_ioctl+0x0/0x3eb
 [<c016a0e1>] do_ioctl+0x51/0x55
 [<c016a1d7>] vfs_ioctl+0x50/0x1aa
 [<c010666f>] do_syscall_trace+0x1e5/0x1fb
 [<c016a38e>] sys_ioctl+0x5d/0x6b
 [<c0102edd>] syscall_call+0x7/0xb
Code: 0d b9 0e 00 00 00 89 e2 89 d8 e8 92 fc ff ff 83 c4 10 5b 5e c3 c6 44 24 06 00
c6 44 24 0c 00 eb b5 56 53 83 ec 10 0f b6 74 24 20 <8b> 58 18 01 db 80 cb 01 88
1c 24 c6 44 24 01 ef c6 44 24 02 15

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

[root@no-torel ~]# rpm -qa | egrep -e "2.6.14-1.1644_FC4|bluez|bluetooth|kmobil|kpp"
[root@no-torel ~]# whereis kppp kppp: /usr/bin/kppp /usr/sbin/kppp
[root@no-torel ~]# rpm -qf /usr/sbin/kppp

How reproducible:

- Yes.  Works fine with all prior kernels, now using 

[root@localhost ~]# uname -ra
Linux localhost.localdomain 2.6.14-1.1637_FC4 #1 Wed Nov 9 18:19:37 EST 2005
i686 i686 i386 GNU/Linux

Steps to Reproduce:
Actual results:

- bluetooth rfcomm0 hangs

Expected results:

- Dial ISP on GPRS Edge (2.75G) or 3G

Additional info:

Email me for more info.
Comment 1 Dave Jones 2005-12-02 00:08:51 EST
can you reproduce this without the binary modules loaded ?
Comment 2 Tore H. Larsen 2005-12-02 01:26:11 EST
Without which modules?  sgil1(U) cisco_ipsec(U) ntfs(U) ?
Comment 3 Dave Jones 2005-12-02 01:36:39 EST
Comment 4 Tore H. Larsen 2005-12-05 11:54:20 EST
    been running without "ntfs" module from

and "sgil1" from SGI L3 SCS-1.12-2 software.  

usbcore: registered new driver sgil1
/opt/L3/sgil1/sgil1_26.c: v4.0 (09/30/2004):USB L3 driver for SGI L1 system

sgil1 and cisco_ipsec was generated with gcc 4.0.2 while kernel is built with
4.0.1. For the last few hours I have been using the cisco_ipsec (vpnclient 4.7).
No problem.   Looks like the ntfs could be the problem, although it is to early
to conclude.  I'll load the module later and see how it goes.

[root@no-torel ~]# rpm -ql kernel-module-ntfs-2.6.14-1.1644_FC4-2.1.24-0.rr.10.4
Comment 5 Tore H. Larsen 2005-12-05 13:47:57 EST
Ok, the problem happens when kppp using /dev/rfcomm0 (bluetooth) in combination
with using vpnclient's module cisco_ipsec 

[root@no-torel log]# dmesg | grep -i cisco
cisco_ipsec: module license 'Proprietary' taints kernel.
Cisco Systems VPN Client Version 4.7.00 (0640) kernel module loaded

Note! The cisco vpnclient 4.7 needed a patch to build with 2.6.14-1.1644_FC4

Found patch on some webpage 

[root@localhost vpnclient-]# diff
linuxcniapi.c.orig  linuxcniapi.c
>     struct timeval timecount;
<     do_gettimeofday(&skb->stamp);
>     do_gettimeofday(&timecount);
>     skb->tstamp.off_sec = (u32) timecount.tv_sec;
>     skb->tstamp.off_usec = (u32) timecount.tv_usec;
>     struct timeval timecount;
<     do_gettimeofday(&skb->stamp);
>     do_gettimeofday(&timecount);
>     skb->tstamp.off_sec = (u32) timecount.tv_sec;
>     skb->tstamp.off_usec = (u32) timecount.tv_usec;

Ok?   Should be easy to reproduce.  I'll test on ealier kernels, but I'm pretty
sure they do not exibit this problem.

Comment 6 Dave Jones 2005-12-06 18:16:20 EST
Only cisco can fix bugs related to cisco_ipsec.
Comment 7 Tore H. Larsen 2005-12-06 19:13:06 EST
As closing remark, I found a tips on Ubuntu.org that works fine. Turns out that
in 2.6.14 skbuff.h  changed from 

struct timeval stamp;


struct skb_timeval tstamp;

Therefore the only change needed is the below:

[root@no-torel vpnclient-]# diff
linuxcniapi.c.orig  linuxcniapi.c
<     do_gettimeofday(&skb->stamp);
>     do_gettimeofday(&skb->tstamp);
<     do_gettimeofday(&skb->stamp);
>     do_gettimeofday(&skb->tstamp);

No more crashes.


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