Re: Segfault on Alpha 1.9.0

[Alain Fauconnet <alain () cscoms net>]

Following up to my own message about:

- SIGSEGV in Snort 1.9.0 on FreeBSD-alpha
- lots of "unaligned access" messages

[...]
> It looks like the argument passed to PreprocUrlDecode is wrong. It  should
> be a valid (Packet *), which 0x1 can't be.
>
> (gdb) p p
> $3 = (Packet *) 0x1

Well, it looks like gdb  has  problem  displaying  the  correct  value
passed as the 'p' argument in many routines. This value showing as 0x1
is probably an artefact. Yes, FreeBSD 4.2 is old, this  box  needs  an
upgrade.

It looks like this case was simpler than I thought:

Program received signal SIGSEGV, Segmentation fault.
0x120054888 in PreprocUrlDecode (p=0x1) at spp_http_decode.c:443   
443         while(index < end && !lookup_whitespace[(u_int)(*index)])

(u_int)(*index) generates a value that is way beyond the allowed 0..255
range for index in lookup_whitespace, so in some cases it raises a SIGSEGV.

It could be because all this is Unicode stuff.

I've changed all (u_int) casts use to generate an index into lookup_whitespace
and lookup_hexvalue to (u_char) in  spp_http_decode.c and  that  fixed
the SIGSEGVs for me (patch attached). 

> I also have gadzillions of unaligned access warnings, all inside
> functions CheckSrcIP and CheckDstIP. I suspect a misaligned structure.
>
> pid 31358 (snort): unaligned access: va=0x120196032 pc=0x12002a210 ra=0x1200293e8 op=ldl
> pid 31358 (snort): unaligned access: va=0x120196036 pc=0x12002a428 ra=0x12002a280 op=ldl

Here, I've tried "uac -s" to debug the thing so that Snort gets a SIGBUS when
unaligned access occurs. Here's what I've got:

Program received signal SIGBUS, Bus error.
BuildPacket (s=0x12005b6f4, stream_size=301968392, p=0x120179970, 
    direction=301968672) at spp_stream4.c:3360
3360            stream_pkt->iph->ip_dst.s_addr = p->iph->ip_src.s_addr;

Can't look at the value of 'p', GDB obviously finds it wrong because the
value is different at one stack frame level upper:

(gdb) bt
#0  BuildPacket (s=0x12005b6f4, stream_size=301968392, p=0x120179970, 
    direction=301968672) at spp_stream4.c:3360
#1  0x12005a5c4 in FlushStream (s=0x12005a5c4, p=0x11ffabd8, 
    direction=538417520) at spp_stream4.c:3241

Let's see the instruction raising the exception:

(gdb) x/i $pc
0x12005ab5c <BuildPacket+412>:  ldq     t0,-28576(gp)

Registers:

(gdb) i r
v0             0x12018e01e      4833468446
t0             0x12018e026      4833468454
t1             0x11ffad20       301968672
t2             0x120163260      4833292896
t3             0x10450008ba07c420       1172343315480691744
t4             0xffff000000000000       -281474976710656
t5             0xffffffff       4294967295
t6             0x601053c2b000   105623241011200
t7             0x1045000800000000       1172343312359620608
s0             0x22     34
s1             0x3c     60
s2             0x120163230      4833292848
s3             0x120160000      4833280000
s4             0x120169fce      4833320910
s5             0x3      3
fp             0x11ffab88       301968264
a0             0x12018e01e      4833468446
a1             0x120163252      4833292882
a2             0x6      6
a3             0x120163258      4833292888
a4             0x12018e024      4833468452
a5             0xffffffffba1a8364       -1172667548
t8             0x160242678      5907949176
---Type <return> to continue, or q <return> to quit--- 
t9             0x1600893a8      5906142120
t10            0x55dc6  351686
t11            0x41c00  269312
ra             0x12005ab00      4832209664
t12            0x1602260c0      5907833024
at             0x160242678      5907949176
gp             0x12008b638      4832409144
sp             0x11ffab88       301968264
zero           0x0      0
pc             0x12005ab5c      4832209756
vfp            0x11ffabd8       301968344

I'm not fluent enough in Alpha machine code to debug this.

I assume that 'ldq' is load quadword, so the problem must be on the
right side of the assigment, when reading p->iph->ip_src.s_addr

The 'Packet' structure is obviously aligned up to 'iph' since there
are only pointers there. So it must be 'iph'? But it exactly maps the
IP header format, so there's little that can be changed here! The
source IP address in there is 32-bit aligned too.

Comments anyone? (I'll Cc: this to freebsd-alpha)

For now, "uac -p" in the Snort startup shell script will at least
avoid the annoying messages.

Greets,
_Alain_

Attachment: spp_http_decode.c.patch
Description: