Kernel module null pointer error when a function is *moved* to another file.

marquisdesade · 03-01-2009, 12:57 PM

Hi,

I have a function for SHA1 computation which I'm trying to test. When I put the function definition in the main module file (i.e., the one that contains module_init and module_exit), it works fine. When I move it to another file (which, of course, is linked), the function runs partially but has a null pointer dereferencing halfway through. I have no idea why this should happen... it's not a linking error since the bug happens somewhere halfway down in the function. I'm using kernel 2.6.22.14.

This is the demsg output (code and makefile attached below):

Code:

28639.008816] test1_init() called
[28639.009313] Getting here3
[28639.009329] Getting here4: 0, 3, 3
[28639.009693] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000010
[28639.010273]  printing eip:
[28639.010413] e09be0c7
[28639.010428] *pde = 00000000
[28639.010708] Oops: 0000 [#1]
[28639.010838] SMP
[28639.011083] Modules linked in: test1mod ipv6 af_packet iptable_filter ip_tables x_tables loop serio_raw psmouse i2c_piix4 i2c_core shpchp pci_hotplug intel_agp agpgart evdev ext3 jbd mbcache sr_mod cdrom sg sd_mod ehci_hcd pcnet32 mii uhci_hcd usbcore ata_piix ata_generic libata BusLogic scsi_mod fuse
[28639.012243] CPU:    0
[28639.012244] EIP:    0060:[<e09be0c7>]    Not tainted VLI
[28639.012246] EFLAGS: 00010202   (2.6.22.14-custom #20)
[28639.012979] EIP is at get_sha1_2+0x8e/0xbf [test1mod]
[28639.013145] eax: dccb5f40   ebx: 00000004   ecx: 00000003   edx: dccb5f48
[28639.013329] esi: 00000003   edi: dccb5f88   ebp: dccb5f64   esp: dccb5f28
[28639.013505] ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
[28639.013698] Process insmod (pid: 3930, ti=dccb4000 task=daef9080 task.ti=dccb4000)
[28639.013885] Stack: dccb5f74 00000000 00000003 00000003 00000000 dccb5f74 00000000 00000000
[28639.014302]        c14137c0 00000173 e09be173 00000003 e09be680 00021c5f dccb5f74 dccb5f98
[28639.014664]        e0857035 e09be177 c013cfc2 00000000 00000000 00000000 00000000 00000000
[28639.015034] Call Trace:
[28639.015290]  [<c0105204>] show_trace_log_lvl+0x19/0x2e
[28639.015744]  [<c01052c6>] show_stack_log_lvl+0x99/0xa1
[28639.015909]  [<c01054c9>] show_registers+0x1b8/0x290
[28639.016065]  [<c01056fa>] die+0x114/0x1ef
[28639.016208]  [<c029ab13>] do_page_fault+0x4d6/0x5b1
[28639.016422]  [<c02991a2>] error_code+0x72/0x80
[28639.016571]  [<e0857035>] test1_init+0x35/0x73 [test1mod]
[28639.016643]  [<c0140095>] sys_init_module+0x93/0x13e
[28639.016706]  [<c0103e12>] sysenter_past_esp+0x6b/0xa9
[28639.016762]  =======================
[28639.019219] Code: c7 04 24 20 e1 9b e0 89 44 24 08 8b 45 e0 89 44 24 04 e8 ff 2f 76 df 8b 45 d8 8d 55 e4 89 f1 8b 5d dc 89 04 24 83 c3 04 8d 45 dc <ff> 53 0c 85 c0 74 13 c7 04 24 3b e1 9b e0 e8 d8 2f 76 df c7 45
[28639.022668] EIP: [<e09be0c7>] get_sha1_2+0x8e/0xbf [test1mod] SS:ESP 0068:dccb5f28

Main kernel module ("test1.c"):

Code:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/syscalls.h>
#include <linux/fcntl.h>
#include <linux/fs.h>
#include <linux/file.h>
#include <asm/uaccess.h>
#include <linux/scatterlist.h>
#include <linux/crypto.h>
#include <linux/string.h>
#include <linux/err.h>

#define KERNEL_2_6_22_14

#include "util.h"

static int __init test1_init(void)
{
  int rc;
  char *plaintext = "abc";
  char digest[21];

  printk(KERN_INFO "test1_init() called\n");

  if ((rc = get_sha1_2(plaintext, strlen(plaintext), digest)))
    printk (KERN_INFO "error with get_sha1: %d\n", rc);
  else {
    printk (KERN_INFO "Got sha1sum of %s: ", plaintext);
    hdump2(digest, 20);
  }

  return 0;
}
void __exit test1_exit(void)
{
  printk(KERN_INFO "test1_exit() called\n");
}

module_init(test1_init);
module_exit(test1_exit);

MODULE_LICENSE("GPL");

This is the "util.c" file which I'm trying to link with test1.c. "util.h" just contains the prototypes for the below two functions. There are a few printks, and it appears that the null pointer dereferencing is happening at the "crypto_hash_digest" call below (although, in the printk just above the call, all arguments are non-null and print just fine). If you just copy these functions to the beginning of test1.c (and not include util.h or link with util.c), it will work fine.

Code:

#include "util.h"

void hdump2(unsigned char *buf, unsigned int len)
{
  while (len--)
    printk("%02x", *buf++);

  printk("\n");
}

int get_sha1_2(char *plaintext, int length, char *digest)
{
  struct scatterlist sg[1];
  struct crypto_hash *tfm = NULL;
  struct hash_desc desc;
  int errcode = 0;

#ifdef KERNEL_2_6_22_14
  tfm = crypto_alloc_hash("sha1", 0, CRYPTO_ALG_ASYNC);
#elif KERNEL_2_6_27_9
  tfm = crypto_alloc_hash("sha1", 0, crypto_alg_async);
#endif
  if (IS_ERR(tfm)) {
    printk(KERN_INFO  "get_sha1: tfm alloc failed.\n");
    errcode = -ENOMEM;
  }

  /* sg_init_one(&sg[0], plaintext, length); */
  sg_set_buf(&sg[0], plaintext, length);

  desc.tfm = tfm;
  desc.flags = 0;

  printk("Getting here3\n");

  memset(digest, 0, 20); /* SHA1 returns 20 bytes */

  printk("Getting here4: %d, %d, %d\n", desc.flags, sg[0].length, length);

  if (crypto_hash_digest(&desc, sg, length, digest)) {
    printk (KERN_INFO "get_sha1: crypto_hash_digest failed.\n");
    errcode = -ERANGE;
  }

  printk("Getting here4\n");

#ifdef KERNEL_2_6_22_14
  crypto_free_hash(tfm);
#elif KERNEL_2_6_27_9
  crypto_free_tfm(tfm);
#endif

  return errcode;
}

util.h:

Code:

#ifndef TEST1_UTIL_H
#define TEST1_UTIL_H

#include <config/crypto/hash.h>
#include <linux/scatterlist.h>
#include <linux/crypto.h>
#include <linux/string.h>
#include <linux/err.h>

void hdump2(unsigned char *buf, unsigned int len);
int get_sha1_2(char *plaintext, int length, char *digest);

#endif

Makefile:

Code:

TARGET := test1mod
obj-m := $(TARGET).o
$(TARGET)-objs := util.o test1.o
KDIR := /data2/work/linux-2.6.22.14/debian/linux-image-2.6.22.14-custom/lib/modules/2.6.22.14-custom/build/
PWD := $(shell pwd)

all: modules

modules:
        make -C $(KDIR) SUBDIRS=$(PWD) modules

clean:
        make -C $(KDIR) M=$(PWD) clean

Valery Reznic · 03-02-2009, 12:23 AM

May be you occasionally changed function name when you moved it to the other file ?

Anyway 'objdump -t <obj_file>' for your *.o and *.ko files can give a bit more information about where your function address lost it's address

sundialsvcs · 03-02-2009, 07:26 AM

Also make sure that all of the affected source-code has been recompiled and relinked ... and of course, reinstalled. (If you're encountering a zero, it's pretty much definite that it hasn't.)

marquisdesade · 03-02-2009, 04:30 PM

Hi,

Valery Reznic, sundialsvcs, thanks for your replies.

Valery Reznic: I've not used objdump before, but how will knowing the offset the call to 'crypto_hash_digest' in 'get_sha1_2' help me debug? What I mean to say is: aren't the addresses printed on the Oops are different from the static .o/.ko files? Thanks for the pointer; I will look further into objdump and also gdb/kgdb.

sundialsvcs: Yes, all sources were recompiled and relinked (in fact, when I replace the sha1 function with a dummy function), other parts of my code also work. As I said, the same function, when defined in test1.c, gives the correct sha1sum.

I'm wondering if it is something to do with the crypto API call, which uses a 'struct scatterlist' to read input to compute the digest. the struct is defined like this (asm-i386/scatterlist.h):

struct scatterlist {
struct page ∗page;
unsigned int offset;
dma_addr_t dma_address;
unsigned int length;
};

This representation (AFAICT) is to speed up hashing large chunks of data (as opposed to hashing small strings). I see a 'do_page_fault' (which could be benign too, i suppose) in the Oops dmesg, so I'm wondering if it's something to do with that.

Thanks for the replies.

Valery Reznic · 03-03-2009, 01:26 AM

[QUOTE=marquisdesade;3462857]Hi,

Valery Reznic, sundialsvcs, thanks for your replies.

Valery Reznic: I've not used objdump before, but how will knowing the offset the call to 'crypto_hash_digest' in 'get_sha1_2' help me debug? What I mean to say is: aren't the addresses printed on the Oops are different from the static .o/.ko files? Thanks for the pointer; I will look further into objdump and also gdb/kgdb.
/QUOTE]

I think after Ooops you have reboot to make another try ?
So if Ooops and objdump provide exactly same information objdump looks like more quick (and safe

way.

You can compare objdump's output for working and not working .ko files.
It may be informative.
Could you post both of them ?