[olug] Hamachi issues on Ubuntu

Fri Jan 29 23:25:55 UTC 2010

--- On Fri, 1/29/10, Charles Bird <cbird.omaha at gmail.com> wrote:

> From: Charles Bird <cbird.omaha at gmail.com>
> Subject: [olug] Hamachi issues on Ubuntu
> To: "Omaha Linux User Group" <olug at olug.org>
> Date: Friday, January 29, 2010, 2:53 AM
> Hi, I'm trying to get Hamachi running
> on an Ubuntu box, and I found this
> guide to aid me:
> http://www.sucka.net/2009/07/install-hamachi-on-ubuntu-9-04/2/
> 
> Everything was running smooth until trying to add it as a
> system svc.
> 
> sudo hamachi-init -c /etc/hamachi
> 
> This results in the output of:
> 
> Killed
> 
> lol
> 
> Heres dmesg, anyone know what this means?

I see the second message where you got it to work.  But if you are interested, here is what happened:

> [41541.629719] BUG: unable to handle kernel NULL pointer
> dereference at
> 00000040

"NULL pointer dereference" means a pointer was set to NULL, i.e. 0, and it was referenced.  This "should not happen", therefore you get an oops.

> [41541.629730] IP: [<c0484430>]
> apparmor_bprm_set_creds+0x370/0x400

IP is the instruction pointer, that means the CPU was executing the instruction at that address.  apparmor is something Novell used to do, dropped in '07, that has many similarities to SELinux.  See the Wikipedia entry for apparmor.  apparmor was minimally incorporated into Gutsy Gibbon and has been more fully implemented since then.

> [41541.629745] *pde = 00000000
> [41541.629748] Oops: 0000 [#3] SMP
> [41541.629751] last sysfs file:
> /sys/devices/pci0000:00/0000:00:09.0/host2/target2:0:0/2:0:0:0/block/sda/uevent
Misc info.

> [41541.629756] Modules linked in: tun binfmt_misc
> snd_wavefront snd_cs4236
> snd_wss_lib snd_opl3_lib snd_hwdep snd_mpu401
> snd_mpu401_uart snd_intel8x0
> snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm
> snd_seq_dummy
> snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event
> snd_seq
> iptable_filter snd_timer snd_seq_device ppdev ip_tables
> nvidia(P) snd ns558
> lp parport_pc x_tables i2c_nforce2 soundcore snd_page_alloc
> shpchp parport
> gameport psmouse serio_raw skge ohci1394 ieee1394 forcedeth
> nvidia_agp
> agpgart

That is the list of modules linked in.  You should get the exact same list with lsmod, but it might be in different order.

> [41541.629791]
> [41541.629796] Pid: 4033, comm: hamachi Tainted: P 
>     D

PID = process id.  See /proc/PID for lots of interesting info on your process. :-)

Tainted means the kernel probably has the NVIDIA binary blob. I.e., it ain't pure no more!

> (2.6.31-14-generic #48-Ubuntu) A7N8X-E

uname -r

A7N8X-E looks like an ASUS  motherboard model.

> [41541.629799] EIP: 0060:[<c0484430>] EFLAGS:
> 00010246 CPU: 0
> [41541.629803] EIP is at
> apparmor_bprm_set_creds+0x370/0x400
> [41541.629806] EAX: fffffffe EBX: cf7f4a00 ECX: ce29bf00
> EDX: cf7f4ce2
> [41541.629809] ESI: 00000000 EDI: cef70b40 EBP: ce29bf44
> ESP: ce29beb4
> [41541.629812]  DS: 007b ES: 007b FS: 00d8 GS: 00e0
> SS: 0068

CPU bits, i.e. register contents.

> [41541.629815] Process hamachi (pid: 4033, ti=ce29a000
> task=f3e64b60
> task.ti=ce29a000)
> [41541.629817] Stack:
> [41541.629819]  ce29bf00 00000000 00000000 ce29bed0
> c01ce8b0 ce2a30b0
> f7001080 ce29beec
> [41541.629826] <0> c01ce8ff 00000000 00000000
> ce2a30b0 00000000 ce2a30b0
> 00000000 000000d0
> [41541.629832] <0> fffffffe c070715a 00000000
> cf7f4ce2 00000000 00000000
> 00000000 00000000

Stack contents.  The ce29???? ones are probably addresses within "this space", i.e. in the part of the code being executed.  The 00000000's are NULLs.  If that is supposed to be a pointer thats going to oops.

> [41541.629839] Call Trace:
> [41541.629846]  [<c01ce8b0>] ?
> __vma_link_rb+0x30/0x40
> [41541.629850]  [<c01ce8ff>] ?
> __vma_link+0x3f/0x80
> [41541.629858]  [<c02c783c>] ?
> security_bprm_set_creds+0xc/0x10
> [41541.629865]  [<c01ecdd1>] ?
> prepare_binprm+0xa1/0xf0
> [41541.629869]  [<c01ed3bb>] ? T.626+0x3b/0x50
> [41541.629873]  [<c01edb2e>] ?
> do_execve+0x17e/0x2c0
> [41541.629878]  [<c0318c45>] ?
> strncpy_from_user+0x35/0x60
> [41541.629882]  [<c0101a28>] ?
> sys_execve+0x28/0x60
> [41541.629886]  [<c010336c>] ?
> syscall_call+0x7/0xb

Call trace,  Follow the stack backwards to see the function history in reverse.  The code was doing an execve (see man 2 execve for details).

> [41541.629888] Code: 24 8b 44 24 18 e8 71 f4 ff ff 3d 00 f0
> ff ff 89 c1 76
> a7 0f b7 44 24 60 f6 c4 40 74 50 c7 44 24 48 5f 71 70 c0 e9
> 98 fe ff ff 90
> <f6> 46 40 08 0f 84 e6 fe ff ff e9 d9 fe ff ff 90 8b
> 54 24 4c 8b

I think this is the actual bytes at EIP.  Don't have my handy-dandy reverse assembler slide rule nearby...

> [41541.629924] EIP: [<c0484430>]
> apparmor_bprm_set_creds+0x370/0x400 SS:ESP
> 0068:ce29beb4
> [41541.629929] CR2: 0000000000000040
> [41541.629933] ---[ end trace a27a09b3bdc0c2b8 ]---

Misc bookkeeping info.

Bottom line?  You rebooted and it worked.  I don't have the source to apparmor or Hamachi (vpn stuff?), running a debugger and looking over the source would pinpoint what happened.  From what I understand of apparmor it just does an advanced ACL (closer to NetWare's ACL, which by the way is the best there is!) so I don't see how something like this could happend unless there is a bug in that code.  (Doesn't check some userspace app supplied filepath for NULL?  If that is what happened then without apparmor this could be a security issue!)

> I'm gonna try on another Linux box, I gotta have this
> working by 9am :/

Sleep is for weenies...

Kevin D. Snodgrass (the grey-beard bit-twiddler...)