For ELF file, how to tell which section contains execution binary code? - elf

I am studying ELF and having a doubt for a while. I tried to search for the answer but in vain. I'd apprciated if somebody could give me the answer or guide me to the place to find an answer.
Almost all the documents I read about ELF said .text section contains executable binary code (and .data contains data....). However, when I used readelf to see the sections contain in an obj file, I saw no .text section but a section called i.main which contains the executable code (from the code contained in this section I found the machine code). The following shows the sections parsed by readelf
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] i.main PROGBITS 00000000 000034 00000a 00 AX 0 0 2
[ 2] .arm_vfe_header PROGBITS 00000000 000040 000004 00 0 0 4
[ 3] .comment PROGBITS 00000000 000044 0001c6 00 0 0 1
[ 4] .debug_frame PROGBITS 00000000 00020a 00003c 00 0 0 1
[ 5] .debug_info PROGBITS 00000000 000246 000088 00 0 0 1
[ 6] .debug_info PROGBITS 00000000 0002ce 0000dc 00 0 0 1
[ 7] .debug_line PROGBITS 00000000 0003aa 000030 00 0 0 1
[ 8] .debug_line PROGBITS 00000000 0003da 000044 00 0 0 1
[ 9] .debug_loc PROGBITS 00000000 00041e 000014 00 0 0 1
[10] .debug_macinfo PROGBITS 00000000 000432 000308 00 0 0 1
[11] .debug_pubnames PROGBITS 00000000 00073a 00001b 00 0 0 1
[12] __ARM_grp..debug_ GROUP 00000000 000758 000008 04 14 14 4
[13] .debug_abbrev PROGBITS 00000000 000760 0005a4 00 G 0 0 1
[14] .symtab SYMTAB 00000000 000d04 000110 10 21 13 4
[15] .rel.debug_frame REL 00000000 000e14 000010 08 14 4 4
[16] .rel.debug_info REL 00000000 000e24 000018 08 14 5 4
[17] .rel.debug_info REL 00000000 000e3c 000038 08 14 6 4
[18] .rel.debug_line REL 00000000 000e74 000008 08 14 8 4
[19] .rel.debug_pubnam REL 00000000 000e7c 000008 08 14 11 4
[20] .shstrtab STRTAB 00000000 000e84 0000f2 00 0 0 1
[21] .strtab STRTAB 00000000 000f76 0001b3 00 0 0 1
[22] .ARM.attributes ARM_ATTRIBUTES 00000000 001129 000044 00 0 0 1
It seems that the section name can be arbitrarily chosen (am I right?) If so, then my questiones are
how to tell which section contains what? (for example, which section contains code and which section contains read only data....).
How to know the definition of each section, for example how do I know the section "[12] __ARM_grp..debug_" is for what purpose?
Thanks in advance.

As for the first part of your question, when determining what sections contain code and which sections contain read only data, a good thing to look for is the section attribute flags.
With the readelf -S command, an X indicates that the section contains executable instructions, an A indicates that the section occupies memory during process execution, and a W indicates that the section should be writable.
So in your object file, there is one section, i.main that is executable, and it is also read only. The other sections aren't writable, but not read only since they aren't in memory at all.
I'm not very familiar with ARM binaries, so I can't really address the other parts of your question.

Related

Where are Kernel global variables stored?

As i know global variables(in userspace programs) are stored in coressponding DATA (and BSS) segment. But how and where are they stored in case of kernel code?
For an example let's look at one of Linux's global variable. Basically, Linux is an ELF image compressed with gzip or other compression tools. As stated on Wikipedia (https://en.wikipedia.org/wiki/Vmlinux):
Traditionally, when creating a bootable kernel image, the kernel is also compressed using gzip, or, since Linux 2.6.30,[3] using LZMA or bzip2, which requires a very small decompression stub to be included in the resulting image. The stub decompresses the kernel code, on some systems printing dots to the console to indicate progress, and then continues the boot process. Support for LZO,[4] xz[5] and LZ4[6] compression was added later.
On Ubuntu, there is a special script called extract-vmlinux which comes with your version of the Linux kernel (https://blog.packagecloud.io/eng/2016/03/08/how-to-extract-and-disassmble-a-linux-kernel-image-vmlinuz/). The Linux ELF file is /boot/vmlinuz. To decompress it, you must use the extract-vmlinux script which can be installed with
sudo apt-get install linux-headers-$(uname -r)
The script is safe to use because it is a standard script which is found in the official repository of packages for your distribution (most packages there are open source and safe). Now use
sudo /usr/src/kernels/$(uname -r)/scripts/extract-vmlinux /boot/vmlinuz-$(uname -r) > vmlinux
to extract the Linux kernel's ELF file from the compressed vmlinux image to your home repository. Now we can look at the ELF file of the Linux kernel. Use readelf -a vmlinux to have a summary of the content. The output for me is this:
user#user-System-Product-Name:~$ readelf -a vmlinux
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x1000000
Start of program headers: 64 (bytes into file)
Start of section headers: 46137728 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 5
Size of section headers: 64 (bytes)
Number of section headers: 35
Section header string table index: 34
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .text PROGBITS ffffffff81000000 00200000
0000000000e025f7 0000000000000000 AX 0 0 4096
[ 2] .rodata PROGBITS ffffffff82000000 01200000
00000000004e46f2 0000000000000000 WA 0 0 4096
[ 3] .pci_fixup PROGBITS ffffffff824e4700 016e4700
00000000000032b0 0000000000000000 A 0 0 16
[ 4] .tracedata PROGBITS ffffffff824e79b0 016e79b0
0000000000000078 0000000000000000 A 0 0 1
[ 5] __ksymtab PROGBITS ffffffff824e7a28 016e7a28
0000000000010a34 0000000000000000 A 0 0 4
[ 6] __ksymtab_gpl PROGBITS ffffffff824f845c 016f845c
00000000000121ec 0000000000000000 A 0 0 4
[ 7] __kcrctab PROGBITS ffffffff8250a648 0170a648
00000000000058bc 0000000000000000 A 0 0 4
[ 8] __kcrctab_gpl PROGBITS ffffffff8250ff04 0170ff04
00000000000060a4 0000000000000000 A 0 0 4
[ 9] __ksymtab_strings PROGBITS ffffffff82515fa8 01715fa8
0000000000037bea 0000000000000001 AMS 0 0 1
[10] __init_rodata PROGBITS ffffffff8254dba0 0174dba0
00000000000002a8 0000000000000000 A 0 0 32
[11] __param PROGBITS ffffffff8254de48 0174de48
00000000000038e0 0000000000000000 A 0 0 8
[12] __modver PROGBITS ffffffff82551728 01751728
00000000000005a0 0000000000000000 WA 0 0 8
[13] __ex_table PROGBITS ffffffff82551cd0 01751cd0
0000000000001af4 0000000000000000 A 0 0 4
[14] .notes NOTE ffffffff825537c4 017537c4
00000000000001ec 0000000000000000 A 0 0 4
[15] .data PROGBITS ffffffff82600000 01800000
00000000003657c0 0000000000000000 WA 0 0 8192
[16] __bug_table PROGBITS ffffffff829657c0 01b657c0
00000000000178d4 0000000000000000 WA 0 0 1
[17] .vvar PROGBITS ffffffff8297e000 01b7e000
0000000000001000 0000000000000000 WA 0 0 16
[18] .data..percpu PROGBITS 0000000000000000 01c00000
000000000002f000 0000000000000000 WA 0 0 4096
[19] .init.text PROGBITS ffffffff829ae000 01dae000
00000000000772e5 0000000000000000 AX 0 0 16
[20] .altinstr_aux PROGBITS ffffffff82a252e5 01e252e5
0000000000002d9b 0000000000000000 AX 0 0 1
[21] .init.data PROGBITS ffffffff82a2a000 01e2a000
00000000001c74f0 0000000000000000 WA 0 0 8192
[22] .x86_cpu_dev.init PROGBITS ffffffff82bf14f0 01ff14f0
0000000000000028 0000000000000000 A 0 0 8
[23] .parainstructions PROGBITS ffffffff82bf1518 01ff1518
0000000000022b7c 0000000000000000 A 0 0 8
[24] .altinstructions PROGBITS ffffffff82c14098 02014098
0000000000006660 0000000000000000 A 0 0 1
[25] .altinstr_replace PROGBITS ffffffff82c1a6f8 0201a6f8
0000000000001789 0000000000000000 AX 0 0 1
[26] .iommu_table PROGBITS ffffffff82c1be88 0201be88
00000000000000f0 0000000000000000 A 0 0 8
[27] .apicdrivers PROGBITS ffffffff82c1bf78 0201bf78
0000000000000040 0000000000000000 WA 0 0 8
[28] .exit.text PROGBITS ffffffff82c1bfb8 0201bfb8
0000000000001f4b 0000000000000000 AX 0 0 1
[29] .smp_locks PROGBITS ffffffff82c1e000 0201e000
000000000000a000 0000000000000000 A 0 0 4
[30] .data_nosave PROGBITS ffffffff82c28000 02028000
0000000000001000 0000000000000000 WA 0 0 4
[31] .bss NOBITS ffffffff82c29000 02029000
00000000005d7000 0000000000000000 WA 0 0 4096
[32] .brk NOBITS ffffffff83200000 02029000
000000000002c000 0000000000000000 WA 0 0 1
[33] .init.scratch PROGBITS ffffffff83400000 02800000
0000000000400000 0000000000000000 WA 0 0 32
[34] .shstrtab STRTAB 0000000000000000 02c00000
0000000000000180 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000200000 0xffffffff81000000 0x0000000001000000
0x00000000015539b0 0x00000000015539b0 R E 0x200000
LOAD 0x0000000001800000 0xffffffff82600000 0x0000000002600000
0x000000000037f000 0x000000000037f000 RW 0x200000
LOAD 0x0000000001c00000 0x0000000000000000 0x000000000297f000
0x000000000002f000 0x000000000002f000 RW 0x200000
LOAD 0x0000000001dae000 0xffffffff829ae000 0x00000000029ae000
0x0000000000e52000 0x0000000000e52000 RWE 0x200000
NOTE 0x00000000017537c4 0xffffffff825537c4 0x00000000025537c4
0x00000000000001ec 0x00000000000001ec 0x4
Section to Segment mapping:
Segment Sections...
00 .text .rodata .pci_fixup .tracedata __ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings __init_rodata __param __modver __ex_table .notes
01 .data __bug_table .vvar
02 .data..percpu
03 .init.text .altinstr_aux .init.data .x86_cpu_dev.init .parainstructions .altinstructions .altinstr_replacement .iommu_table .apicdrivers .exit.text .smp_locks .data_nosave .bss .brk .init.scratch
04 .notes
There is no dynamic section in this file.
There are no relocations in this file.
The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported.
No version information found in this file.
Displaying notes found in: .notes
Owner Data size Description
Xen 0x00000006 Unknown note type: (0x00000006)
description data: 6c 69 6e 75 78 00
Xen 0x00000004 Unknown note type: (0x00000007)
description data: 32 2e 36 00
Xen 0x00000008 Unknown note type: (0x00000005)
description data: 78 65 6e 2d 33 2e 30 00
Xen 0x00000008 Unknown note type: (0x00000003)
description data: 00 00 00 80 ff ff ff ff
Xen 0x00000008 Unknown note type: (0x0000000f)
description data: 00 00 00 00 80 00 00 00
Xen 0x00000008 NT_VERSION (version)
description data: c0 e1 9a 82 ff ff ff ff
Xen 0x00000008 NT_ARCH (architecture)
description data: 00 20 00 81 ff ff ff ff
Xen 0x00000029 Unknown note type: (0x0000000a)
description data: 21 77 72 69 74 61 62 6c 65 5f 70 61 67 65 5f 74 61 62 6c 65 73 7c 70 61 65 5f 70 67 64 69 72 5f 61 62 6f 76 65 5f 34 67 62
Xen 0x00000004 Unknown note type: (0x00000011)
description data: 01 88 00 00
Xen 0x00000004 Unknown note type: (0x00000009)
description data: 79 65 73 00
Xen 0x00000008 Unknown note type: (0x00000008)
description data: 67 65 6e 65 72 69 63 00
Xen 0x00000010 Unknown note type: (0x0000000d)
description data: 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
Xen 0x00000004 Unknown note type: (0x0000000e)
description data: 01 00 00 00
Xen 0x00000004 Unknown note type: (0x00000010)
description data: 01 00 00 00
Xen 0x00000008 Unknown note type: (0x0000000c)
description data: 00 00 00 00 00 80 ff ff
Xen 0x00000008 Unknown note type: (0x00000004)
description data: 00 00 00 00 00 00 00 00
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: c0263a3075bc0a9388365ddf35ab5422da3356a9
Linux 0x00000001 OPEN
description data: 00
Xen 0x00000008 Unknown note type: (0x00000012)
description data: 40 07 00 01 00 00 00 00
The important section for the question is the Program headers section:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000200000 0xffffffff81000000 0x0000000001000000
0x00000000015539b0 0x00000000015539b0 R E 0x200000
LOAD 0x0000000001800000 0xffffffff82600000 0x0000000002600000
0x000000000037f000 0x000000000037f000 RW 0x200000
LOAD 0x0000000001c00000 0x0000000000000000 0x000000000297f000
0x000000000002f000 0x000000000002f000 RW 0x200000
LOAD 0x0000000001dae000 0xffffffff829ae000 0x00000000029ae000
0x0000000000e52000 0x0000000000e52000 RWE 0x200000
NOTE 0x00000000017537c4 0xffffffff825537c4 0x00000000025537c4
0x00000000000001ec 0x00000000000001ec 0x4
I would guess that the RW sections are the data/bss segments of the static and freestanding kernel image. There isn't much bss data (uninitialized data) in this kernel image. You can see that by looking at the filesize versus the memsize of the different segments. In bss data, only the size is written in the executable. The loader will then assign zeroes to these segments. Since we have only memsizes which are equal to the filesizes, then we don't have much bss here.
Also, we can look at the different virtual addresses at which the kernel will load itself after decompression. This will be useful to find the segment in which a certain global variable resides.
Now, to determine where a global variable is loaded one can look at the System.map file in the /boot directory. For example, we can take a random global variable in kernel/sched/core.c called sysctl_sched_rt_period and find its address using
user#user-System-Product-Name:~$ sudo grep "sysctl_sched_rt_period" /boot/System.map-$(uname -r)
ffffffff8266eb24 D sysctl_sched_rt_period
The address is thus ffffffff8266eb24. This address resides in the RW segment loaded at ffffffff82600000 because the size of this segment is 37f000 and because ffffffff82600000 + 37f000 > ffffffff8266eb24. You can clearly see that this global variable is stored in the data segment of the kernel's executable.

non-matching XRef stream entry size

I'm trying to read an XRef stream object but something doesn't adds up. This is my object:
<<
/DecodeParms << /Columns 5/Predictor 12 >>
/Filter /FlateDecode
/ID [<9597C618BC90AFA4A078CA72B2DD061C><48726007F483D547A8BEFF6E9CDA072F>]
/Index [124332 848]
/Info 124331 0 R
/Length 137
/Prev 8983958
/Root 124333 0 R
/Size 125180
/Type /XRef
/W [1 3 1]
>>
I read the 137 bytes of stream, uncompress them through zlib and I get 5088 bytes. This is the beginning of the uncompressed stream (hexdump -C output):
00000000 02 01 00 00 10 00 02 00 00 27 ec 00 02 00 00 01 |.........'......|
00000010 f4 00 02 00 00 01 f7 00 02 00 00 04 5b 00 02 00 |............[...|
00000020 00 02 68 00 02 00 00 0b ac 00 02 00 00 0f e5 00 |..h.............|
00000030 02 00 00 0e 93 00 02 00 00 0d 14 00 02 00 00 0d |................|
What I don't understand is that I should have 5 bytes per entry: /W [1 3 1] means 1+3+1=5 bytes; but the stream's length of 5088 isn't divisible by 5. Also, I realized that 5088 is divisible by 6: 5088/6=848 and that's the number of entry as the second value of the /Index key confirms. Reading the stream keeping the [1 3 1] scheme is, also, impossible already at the second entry (the byte 0xEC isn't a valid entry type).
Where's my mistake?
Thanks a lot for any help.
After decompression each line has 6 bytes: 1 byte for predictor, 5 for 'predicted' data.
After you apply the predictor you get the actual data.

What does this mean from logwatch? Kernel errors

I have received this in my daily logwatch report. I do not know what this means. I am concerned that my server is about to fail. I do not know enough to know what this data means.
--------------------- Kernel Begin ------------------------
WARNING: Kernel Errors Present
res 41/01:00:90:20:6c/00:00:1b:00:00/40 Emask 0x401 (device error) <F> ...: 4 Time(s)
res 41/40:00:90:20:6c/00:00:1b:00:00/40 Emask 0x409 (media error) <F> ...: 1 Time(s)
res 51/01:00:90:20:6c/00:00:1b:00:00/e0 Emask 0x1 (device error) ...: 6 Time(s)
res 51/40:00:90:20:6c/00:00:1b:00:00/e0 Emask 0x9 (media error) ...: 7 Time(s)
ata1.00: NCQ disabled due to excessive errors ...: 1 Time(s)
ata1.00: error: { UNC } ...: 8 Time(s)
sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocat ...: 2 Time(s)
sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descr ...: 3 Time(s)
3 Time(s): 1b 6c 20 90
2 Time(s): 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
1 Time(s): 72 03 13 00 00 00 00 0c 00 0a 80 00 00 00 00 00
3 Time(s): Descriptor sense data with sense descriptors (in hex):
13 Time(s): ata1.00: cmd 25/00:08:90:20:6c/00:00:1b:00:00/e0 tag 0 dma 4096 in
5 Time(s): ata1.00: cmd 60/08:00:90:20:6c/00:00:1b:00:00/40 tag 0 ncq 4096 in
18 Time(s): ata1.00: configured for UDMA/133
13 Time(s): ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
5 Time(s): ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
13 Time(s): ata1.00: failed command: READ DMA EXT
5 Time(s): ata1.00: failed command: READ FPDMA QUEUED
13 Time(s): ata1.00: irq_stat 0x40000001
5 Time(s): ata1.00: irq_stat 0x40000008
18 Time(s): ata1.00: status: { DRDY ERR }
18 Time(s): ata1: EH complete
1 Time(s): sd 0:0:0:0: [sda] Add. Sense: Address mark not found for data field
3 Time(s): sd 0:0:0:0: [sda] CDB: Read(10): 28 00 1b 6c 20 90 00 00 08 00
3 Time(s): sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
3 Time(s): sd 0:0:0:0: [sda] Unhandled sense code
---------------------- Kernel End -------------------------
ATA could be the hard disks. I'd suggest to test them if possible. Or check the filesystem.

reading a pdf version >= 1.5, how to handle Cross Reference Stream Dictionary

I'm trying to read the xref table of a pdf version >= 1.5.
the xref table is an object:
58 0 obj
<</DecodeParms<</Columns 4/Predictor 12>>/Filter/FlateDecode/ID[<CB05990F613E2FCB6120F059A2BCA25B><E2ED9D17A60FB145B03010B70517FC30>]/Index[38 39]/Info 37 0 R/Length 96/Prev 67529/Root 39 0 R/Size 77/Type/XRef/W[1 2 1]>>stream
hÞbbd``b`:$AD`­Ì ‰Õ Vˆ8âXAÄ×HÈ$€t¨ – ÁwHp·‚ŒZ$ìÄb!&F†­ .#5‰ÿŒ>(more here but can't paste)
endstream
endobj
as you can see
/FlatDecode
/Index [38 39], that is 39 entries in the stream
/W [1 2 1] that is each entry is 1 + 2 + 1 = 4 bytes long
/Root 39 0 R that is root object is number 39
BUT :
the decompressed stream is 195 bytes long (39 * 5 = 195). So the length of an entry is 4 or 5.
Here is the first inflated bytes
02 01 00 10 00 02 00 02 cd 00 02 00 01 51 00 02 00 01 70 00 02 00 05 7a 00 02
^^
if entry length is 4 then the root entry is a free object (see the ^^) !!
if the entry is 5: how to interpret the fields of one entry (reference is implicitly made to PDF Reference, chapter 3.4.7 table 3.16 ) ?
For object 38, the first of the stream: it seems, as it is of type 2, to be the 16 object of the stream object number 256, but there is no object 256 in my pdf file !!!
The question is: how shall I handle the 195 bytes ?
A compressed xref table may have been compressed with one of the PNG filters. If the /Predictor value is set to '10' or greater ("a Predictor value greater than or equal to 10 merely indicates that a PNG predictor is in use; the specific predictor function used is explicitly encoded in the incoming data")1, PNG row filters are supplied inside the compressed data "as usual" (i.e., in the first byte of each 'row', where the 'row' is of the width in /W).
Width [1 2 1] plus Predictor byte:
02 01 00 10 00
02 00 02 cd 00
02 00 01 51 00
02 00 01 70 00
02 00 05 7a 00
02 .. .. .. ..
After applying the row filters ('2', or 'up', for all of these rows), you get this:
01 00 10 00
01 02 ed 00
01 03 3e 00
01 04 ae 00
01 09 28 00
.. .. .. ..
Note: calculated by hand; I might have made the odd mistake here and there. Note that the PNG 'up' filter is a byte filter, and the result of the "up" filter is truncated to 8 bits for each addition.
This leads to the following Type 1 XRef references ("type 1 entries define objects that are in use but are not compressed (corresponding to n entries in a cross-reference table)."):2
#38 type 1: offset 10h, generation 0
#39 type 1: offset 2EDh, generation 0
#40 type 1: offset 33Eh, generation 0
#41 type 1: offset 4AEh, generation 0
#42 type 1: offset 928h, generation 0
1 See LZW and Flate Predictor Functions in PDF Reference 1.7, 6th Ed, Section 3.3: Filters.
2 As described in your Table 3.16 in PDF Ref 1.7.

PANIC: "Oops: 0000 [#1]" (check log for details) - Updated Kernel Tested

I'm trying to interpret a system crash that is repeatable, but but not that often. I believe it has do with a third party driver and a optical scanning device. I'm not sure if the driver for scanning device is causing the hang if it's bringing something out in a USB driver that causes the hang or if it's something totally different.
I'm not a driver developer, so I'm fumbling my way through the crash dump while reading the Linux Kernel Crash Book located here - http://rogunix.com/docs/Reversing&Exploiting/Linux_Kernel_Crash_Book.pdf .
I was able to setup a debug kernel with the kexec tools to produce a vmcore. With crash is see the PANIC: "Oops: 0000 [#1]" (check log for details) and in the logs is see the BUG: unable to handle kernel paging request at virtual address 00100100.
Can you help me interpret more of the dump so I can go back to the developer of the driver and tell them the findings or can you tell me is not the driver at all.
Here's more from the dump. Many thanks in advance.
KERNEL: /usr/lib/debug/lib/modules/2.6.18-194.el5debug/vmlinux
DUMPFILE: /root/kernel/vmcore_12032014
CPUS: 4
DATE: Sat Oct 20 16:51:55 2001
UPTIME: 00:03:55
LOAD AVERAGE: 0.79, 0.83, 0.38
TASKS: 128
NODENAME: 3232A
RELEASE: 2.6.18-194.el5debug
VERSION: #1 SMP Fri Apr 2 16:56:41 EDT 2010
MACHINE: i686 (1800 Mhz)
MEMORY: 2 GB
PANIC: "Oops: 0000 [#1]" (check log for details)
PID: 0
COMMAND: "swapper"
TASK: c069d460 (1 of 4) [THREAD_INFO: c075f000]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 0 TASK: c069d460 CPU: 0 COMMAND: "swapper"
#0 [c080cdb0] crash_kexec at c044a386
#1 [c080cdf4] die at c04065c3
#2 [c080ce24] do_page_fault at c062d1b7
#3 [c080ce5c] error_code (via page_fault) at c0405bc3
EAX: f7c7de2c EBX: 000ffaec ECX: 00000000 EDX: f4282e8c EBP: f7c665a0
DS: 007b ESI: f7c7ddf8 ES: 007b EDI: c080cea4
CS: 0060 EIP: c05a2ef2 ERR: ffffffff EFLAGS: 00010012
#4 [c080ce90] hiddev_send_event at c05a2ef2
#5 [c080cea0] hiddev_report_event at c05a2fcc
#6 [c080cec8] hid_input_report at c05a0fc3
#7 [c080cf1c] hid_irq_in at c05a261d
#8 [c080cf2c] usb_hcd_giveback_urb at c05964b6
#9 [c080cf3c] uhci_giveback_urb at f883f618 [uhci_hcd]
#10 [c080cf58] uhci_scan_schedule at f883fc14 [uhci_hcd]
#11 [c080cfa4] uhci_irq at f884163d [uhci_hcd]
#12 [c080cfc4] usb_hcd_irq at c0596f9b
#13 [c080cfcc] handle_IRQ_event at c0454d5f
#14 [c080cfe4] __do_IRQ at c0454e2d
--- <hard IRQ> ---
#0 [c075ff80] do_IRQ at c040761f
#1 [c075ff98] common_interrupt at c0405a28
EAX: 00000000 EBX: c075f008 ECX: 00000000 EDX: 00000000 EBP: 00000020
DS: 007b ESI: c06440f8 ES: 007b EDI: ca138790
CS: 0060 EIP: c0403d0a ERR: ffffff4e EFLAGS: 00000246
#2 [c075ffcc] mwait_idle at c0403d0a
#3 [c075ffd4] cpu_idle at c0403cc4
crash> log
Scan: First buffer received = 0x6
Scan: Last packet of command transfer = 6 Command size 6
Scan: 0x2 0x51 0x88 0x80 0x81 0x3
Scan: Read data present
Scan: IOCTL_PS3_PEAK_MSG
Scan: In scanner_read Scan: Copied 1 chunks of data to user space
usb 4-1: new full speed USB device using uhci_hcd and address 3
usb 4-1: configuration #1 chosen from 1 choice
pl2303 4-1:1.0: pl2303 converter detected
usb 4-1: pl2303 converter now attached to ttyUSB0
BUG: unable to handle kernel paging request at virtual address 00100100
printing eip:
c05a2ef2
*pde = 76330067
Oops: 0000 [#1]
SMP
last sysfs file: /devices/pci0000:00/0000:00:1d.2/usb4/4-1/bConfigurationValue
Modules linked in: vfat fat scan_drv_scanner(U) xt_limit xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables loop dm_mirror dm_multipath scsi_dh video backlight sbs power_meter hwmon i2c_ec dell_wmi wmi button battery asus_acpi ac lp joydev snd_hda_intel snd_seq_dummy sg snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc parport_pc serio_raw snd_hwdep parport pl2303 snd soundcore i2c_i801 usbserial r8169 i2c_core mii pcspkr dm_raid45 dm_message dm_region_hash dm_log dm_mod dm_mem_cache usb_storage ata_piix libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
CPU: 0
EIP: 0060:[<c05a2ef2>] Tainted: G VLI
EFLAGS: 00010012 (2.6.18-194.el5debug #1)
EIP is at hiddev_send_event+0x65/0x95
eax: f7c7de2c ebx: 000ffaec ecx: 00000000 edx: f4282e8c
esi: f7c7ddf8 edi: c080cea4 ebp: f7c665a0 esp: c080ce94
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, ti=c080c000 task=c069d460 task.ti=c075f000)
Stack: f7cbba78 ca3ec000 c080cebc c05a2fd1 00000001 00000001 ffffffff 00000000
00000000 00000000 00000005 f7cc857c c075ff9c c05a0fc8 f7c57348 00000002
00000002 00000046 c06cbfb0 00000001 ca3ec000 f7cca001 f7cbba78 00000046
Call Trace:
[<c05a2fd1>] hiddev_report_event+0x4b/0x52
[<c05a0fc8>] hid_input_report+0x99/0x399
[<c05a2622>] hid_irq_in+0x49/0xcc
[<c05964b9>] usb_hcd_giveback_urb+0x28/0x53
[<f883f61d>] uhci_giveback_urb+0x104/0x12b [uhci_hcd]
[<f883fc19>] uhci_scan_schedule+0x4f0/0x76b [uhci_hcd]
[<f8841642>] uhci_irq+0x118/0x12e [uhci_hcd]
[<c0596f9e>] usb_hcd_irq+0x23/0x50
[<c0454d61>] handle_IRQ_event+0x3e/0x8a
[<c0454e32>] __do_IRQ+0x85/0xda
[<c0454dad>] __do_IRQ+0x0/0xda
[<c040761f>] do_IRQ+0xa4/0xd1
[<c0405a2d>] common_interrupt+0x25/0x2c
[<c0403d0a>] mwait_idle+0x2a/0x3d
[<c0403cc6>] cpu_idle+0xa4/0xbe
[<c0764a22>] start_kernel+0x39e/0x3a6
=======================
Code: b9 01 00 02 00 ba 1d 00 00 00 40 83 e0 3f 89 83 00 06 00 00 8d 83 0c 06 00 00 e8 93 ac ee ff 8b 9b 14 06 00 00 81 eb 14 06 00 00 <8b> 83 14 06 00 00 0f 18 00 90 8d 93 14 06 00 00 8d 46 34 39 c2
EIP: [<c05a2ef2>] hiddev_send_event+0x65/0x95 SS:ESP 0068:c080ce94
Updated Kernel Tested
I have since updated to the latest CentOS 5.5 released kernel (2.6.18-371.6.1), but still got a kernel panic. However this time the panic occured on the command "khubd" and not on "swapper". I was able to capture the dump and below I have provided what I hope is relevant information to pinpoint this problem. Is it a bug in the kernel or something in the driver?
KERNEL: /usr/lib/debug/lib/modules/2.6.18-371.6.1.el5debug/vmlinux
DUMPFILE: /root/kernel2/HWID-2277-31032014/vmcore
CPUS: 4
DATE: Mon Mar 31 12:50:25 2014
UPTIME: 2 days, 19:29:28
LOAD AVERAGE: 0.07, 0.09, 0.02
TASKS: 181
NODENAME: 32277
RELEASE: 2.6.18-371.6.1.el5debug
VERSION: #1 SMP Wed Mar 12 22:29:36 EDT 2014
MACHINE: i686 (1800 Mhz)
MEMORY: 2 GB
PANIC: "Oops: 0000 [#1]" (check log for details)
PID: 126
COMMAND: "khubd"
TASK: ca2fc5b0 [THREAD_INFO: f7fb2000]
CPU: 3
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 126 TASK: ca2fc5b0 CPU: 3 COMMAND: "khubd"
#0 [f7fb2dfc] crash_kexec at c044da51
#1 [f7fb2e40] die at c0406649
#2 [f7fb2e70] do_page_fault at c0639449
#3 [f7fb2eb0] device_del at c057053e
#4 [f7fb2efc] device_del at c0570552
#5 [f7fb2f10] device_unregister at c0570669
#6 [f7fb2f18] usb_remove_ep_files at c05a3dac
#7 [f7fb2f38] usb_remove_sysfs_dev_files at c05a39d6
#8 [f7fb2f44] usb_disconnect at c059db59
#9 [f7fb2f58] hub_thread at c059e663
#10 [f7fb2fcc] kthread at c0439ef6
#11 [f7fb2fe4] kernel_thread_helper at c0405e0d
crash> log (truncated)
Scan: no error - In command_callback
Scan: In command_callback
Scan: First buffer received = 0x2a
Scan: Last packet of command transfer = 42 Command size 42
Scan: 0x2 0x44 0x20 0x54 0x65 0x73 0x74 0x20 0x4d 0x65 0x73 0x73
Scan: Read data present
Scan: IOCTL_PS3_PEAK_MSG
Scan: In scanner_read Scan: Copied 1 chunks of data to user space
Scan: IOCTL_PS3_SCANNER_COMMAND Busy slots = 0x0 Total_slots = 0x8 Busy image slots = 0x0
Scan: 0x2 0x38 0x3 0x4
Scan: In write_callback status = 0x0
Scan: In image_callback
Scan: Urb status = 0xffffffb9 Urb length = 0x0
Scan: In image_callback_fun - lost connection to scanner.
Scan: urb set to re-submit
Scan: In command_callback
Scan: Urb status = 0xffffffb9 Urb length = 0x0
Scan: In command_callback_fun - lost connection to scanner.
Scan: urb set to re-submit
usb 1-6: USB disconnect, address 11
BUG: unable to handle kernel paging request at virtual address 6b6b6b93
printing eip:
c04bd310
*pde = 00000000
Oops: 0000 [#1]
SMP
last sysfs file: /devices/pci0000:00/0000:00:1d.7/usb1/1-6/bConfigurationValue
Modules linked in: vfat fat pdi_ps3_drv_scanner(U) xt_limit xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables loop dm_mirror dm_multipath scsi_dh video backlight sbs power_meter hwmon i2c_ec dell_wmi wmi button battery asus_acpi ac lp joydev snd_hda_intel snd_seq_dummy sg snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer parport_pc snd_page_alloc snd_hwdep snd parport tpm_tis tpm soundcore r8169 tpm_bios i2c_i801 serio_raw pcspkr pl2303 usbserial mii i2c_core dm_raid45 dm_message dm_region_hash dm_log dm_mod dm_mem_cache usb_storage ata_piix libata sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
CPU: 3
EIP: 0060:[<c04bd310>] Tainted: G -------------------- VLI
EFLAGS: 00010202 (2.6.18-371.6.1.el5debug #1)
EIP is at sysfs_hash_and_remove+0x18/0x103
eax: 6b6b6b6b ebx: f4be5bf4 ecx: c0570543 edx: 6b6b6b6b
esi: f4be5b0c edi: f3cd936c ebp: f3cd93c4 esp: f7fb2ee0
ds: 007b es: 007b ss: 0068
Process khubd (pid: 126, ti=f7fb2000 task=ca2fc5b0 task.ti=f7fb2000)
Stack: f4be5c50 6b6b6b6b f764d16c f4be5bf4 f4be5b0c f3cd936c f3cd93c4 c0570557
f4be5b0c f3cd93a0 f3cd936c f7c8da2c c057066e f7fb2f28 c05a3db1 f7fb2f28
c06827a6 00000000 305f7065 c06d0030 f3cd936c f3cd93c4 c05a39db f3cd96cc
Call Trace:
[<c0570557>] device_del+0x5c/0x16b
[<c057066e>] device_unregister+0x8/0x10
[<c05a3db1>] usb_remove_ep_files+0x53/0x75
[<c05a39db>] usb_remove_sysfs_dev_files+0xf/0x6c
[<c059db5e>] usb_disconnect+0xa7/0xe0
[<c059e668>] hub_thread+0x327/0x987
[<c0439ed9>] kthread+0xa1/0xec
[<c0439fab>] autoremove_wake_function+0x0/0x2d
[<c059e341>] hub_thread+0x0/0x987
[<c0439ef8>] kthread+0xc0/0xec
[<c0439e38>] kthread+0x0/0xec
[<c0405e0f>] kernel_thread_helper+0x7/0x10
=======================
Code: 8b 40 24 8b 40 40 c3 8b 40 14 8b 00 c3 8b 40 14 8b 00 c3 55 57 56 53 83 ec 0c 85 c0 89 44 24 04 89 14 24 0f 84 e5 00 00 00 89 c2 <8b> 40 28 85 c0 0f 84 d8 00 00 00 8b 52 70 05 90 00 00 00 89 54
EIP: [<c04bd310>] sysfs_hash_and_remove+0x18/0x103 SS:ESP 0068:f7fb2ee0