2011-07-20 14:02:27     NULL pointer access - BOA and CGIC to file upload

Document created by Aaronwu Employee on Aug 27, 2013
Version 1Show Document
  • View in full screen mode

2011-07-20 14:02:27     NULL pointer access - BOA and CGIC to file upload

wag hanna (UNITED STATES)

Message: 102552   

 

I'm running on an EZKIT-LITE target, and using BOA web server with CGIC 2.05. When I submit a file upload the targetcrashes and returns "NULL pointer access" or "Data access CPLB miss". I tried running the cgictest.cgi program as an example and the same thing happens.  I'm at a loss as to what's causing this problem and what else I should try.

QuoteReplyEditDelete

 

 

2011-07-20 14:17:53     Re: NULL pointer access - BOA and CGIC to file upload

Mike Frysinger (UNITED STATES)

Message: 102553   

 

make sure the file was transferred correctly (such as using ftp in binary mode)

 

also make sure you arent overflowing the stack:

  docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:debugging_applications

 

otherwise, post the actual crash message you're seeing

QuoteReplyEditDelete

 

 

2011-07-20 14:35:20     Re: NULL pointer access - BOA and CGIC to file upload

wag hanna (UNITED STATES)

Message: 102554   

 

I'm trying to upload a file from a web browser, not an FTP client. The test HTML with file input looks like this:

 

---

 

<html>

<head>

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

<title>Test Upload</title>

</head>

<body>

<form action="/cgi-bin/ephone" method="post" enctype="multipart/form-data" target="_blank">

<input type="file" name="file" value="" />

<input type="submit" name="submit" value="OK">

</form>

</body>

</html>

 

---

 

I simplified my CGI program to just contain handling for the file upload, and the target is not crashing anymore but I'm not able to receive the file transfer.. test CGI program looks like this:

 

---

 

#include<stdio.h>

#include<string.h>

#include<unistd.h>

#include<fcntl.h>

#include<sys/stat.h>

#include"cgic.h"

#define BufferLen 1024

int cgiMain(void){

    cgiFilePtr file;

    char name[1024];

    char contentType[1024];

    char buffer[1024];

    int size;

    int got;

    FILE * dbg = NULL;

    dbg = fopen("debug", "w");

    if (cgiFormFileName("file", name, sizeof(name)) != cgiFormSuccess) {

        fprintf(dbg,"\nNo file was uploaded.\n");

        fflush(dbg);

        //return;

    }

    fprintf(dbg, "The filename submitted was: %s", name);fflush(dbg);

  

  

    cgiFormFileSize("file", &size);

    fprintf(dbg, "\nThe file size was: %d bytes", size);fflush(dbg);

    cgiFormFileContentType("file", contentType, sizeof(contentType));

    fprintf(dbg, "The alleged content type of the file was: %s", contentType);

    fflush(dbg);

  

  

    fprintf(dbg, "Of course, this is only the claim the browser made when uploading the file. Much like the filename, it cannot be trusted.\n");

    fflush(dbg);

    fprintf(dbg, "The file's contents are shown here:\n");

    if (cgiFormFileOpen("file", &file) != cgiFormSuccess) {

        fprintf(dbg, "Could not open the file.\n");

        return;

    }

  

    while (cgiFormFileRead(file, buffer, sizeof(buffer), &got) ==

        cgiFormSuccess)

    {

        fprintf(dbg, "\n%s", buffer);fflush(dbg);

    }

  

    cgiFormFileClose(file);

 

    return 0;

}

 

---

 

program output shows that every CGIC call failed to open/retrieve file upload, as follows:

 

---

 

No file was uploaded.

The filename submitted was:

The file size was: 0 bytesThe alleged content type of the file was: Of course, .

The file's contents are shown here:

Could not open the file.

QuoteReplyEditDelete

 

 

2011-07-20 14:52:31     Re: NULL pointer access - BOA and CGIC to file upload

wag hanna (UNITED STATES)

Message: 102555   

 

Maybe the problem is the file system location where the file uploads will dump to. How do I set the location for file uploads in BOA configuration? I read on the UPLOADDIR in cgihtml, but I'm not using that library, and the BOA conf doesn't have the UPLOADDIR or any other similar that I could find...

QuoteReplyEditDelete

 

 

2011-07-20 16:06:23     Re: NULL pointer access - BOA and CGIC to file upload

Mike Frysinger (UNITED STATES)

Message: 102556   

 

i'm not talking about your browser.  boa is executing some binary, and *that* program is what i'm talking about transferring via ftp.

 

if you're building that code as FLAT (bfin-uclinux), then most likely you're smashing the stack and corrupting random memory.  please refer to the documentation i already posted.

QuoteReplyEditDelete

 

 

2011-07-21 10:05:43     Re: NULL pointer access - BOA and CGIC to file upload

wag hanna (UNITED STATES)

Message: 102597   

 

I assumed the FTP app is built-in the BOA server, don't know how to check if the binary transfer succeeded?

 

You're right - the code is built as FLAT, I don't follow why the stack is overrun when a file upload occurs. Are you saying that if the application needs to support file uploads, then a different build format than FLAT is necessary? Please give me a better hint.

 

Here's the crash output --- this time it's outputting Data access misaligned, sometimes it outputs NULL pointer access, other times it's CPLB miss, so the messages are inconsistent - that could be pointing to what you were beginning to explain about corrupted random access memory, each time producing a different exception...

 

---

 

root:/etc> Data access misaligned address violation

<5> - Attempted misaligned data memory or data cache access.

Deferred Exception context

CURRENT PROCESS:

COMM=ephone PID=230  CPU=0

TEXT = 0x02ea0040-0x02eac280        DATA = 0x02eac2a0-0x02eb1570

BSS = 0x02eb1570-0x02eb26c0  USER-STACK = 0x02eb3c88

 

return address: [0x02ea7196]; contents of:

0x02ea7170:  67e1  e100  126c  e300  015f  3038  e140  02eb

0x02ea7180:  e14a  02ea  e100  1270  e10a  7b4c  0062  0c07

0x02ea7190:  1c06  3217  b9f0 [9210] 0c42  1407  e3ff  f05c

0x02ea71a0:  3210  6060  9310  6802  e801  0000  3042  0530

 

ADSP-BF537-0.3 500(MHz CCLK) 125(MHz SCLK) (mpu off)

Linux version 2.6.34.7-ADI-2010R1 (root@col0R1-RC4) ) #246 Wed Jul 20 15:56:23 1

 

SEQUENCER STATUS:               Not tainted

SEQSTAT: 00062024  IPEND: 0008  IMASK: ffff  SYSCFG: 0006

  EXCAUSE 0000> /* Maybe null pointer? */

RETN: <0x02c3c000> /* kernel dynamic memory */

RETX: <0x00000480> /* Maybe fixed code section */

RETS: <0x02ea7112> [ ephone + 0x70d2 ]

PC  : <0x02ea7196> [ ephone + 0x7156 ]

DCPLB_FAULT_ADDR: <0xd5bde65c> /* reserved memory */

ICPLB_FAULT_ADDR: <0x02ea7196> [ ephone + 0x7156 ]

PROCESSOR STATE:

R0 : 00000054    R1 : 00000054    R2 : 2d2d2d2d    R3 : 02eb1380

R4 : 02ead744    R5 : ffffffff    R6 : 00000241    R7 : d5bde65f

P0 : 02eb126c    P1 : 00000001    P2 : d5bde65f    P3 : 00000000

P4 : 02eb2234    P5 : 02eb2260    FP : 02eb3b60    SP : 02c3bf24

LB0: 02ea6bf9    LT0: 02ea6bf6    LC0: 00000000

LB1: 02ea5ef9    LT1: 02ea5ef8    LC1: 00000000

B0 : 00000000    L0 : 00000000    M0 : 000000f2    I0 : 02eb229a

B1 : 00000000    L1 : 00000000    M1 : 00000000    I1 : 02eac4c8

B2 : 00000000    L2 : 00000000    M2 : 00000000    I2 : 00000000

B3 : 00000000    L3 : 00000000    M3 : 00000000    I3 : 00000000

A0.w: 00000003   A0.x: 00000000   A1.w: 00000003   A1.x: 00000000

USP : 02eb3b44  ASTAT: 02003006

 

Hardware Trace:

   0 Target : <0x00003efc> { _trap_c + 0x0 }

     Source : <0xffa00744> { _exception_to_level5 + 0xa4 } CALL pcrel

   1 Target : <0xffa006a0> { _exception_to_level5 + 0x0 }

     Source : <0xffa00554> { _bfin_return_from_exception + 0x18 } RTX

   2 Target : <0xffa0053c> { _bfin_return_from_exception + 0x0 }

     Source : <0xffa005f8> { _ex_trap_c + 0x74 } JUMP.S

   3 Target : <0xffa00584> { _ex_trap_c + 0x0 }

     Source : <0xffa0080a> { _trap + 0x5a } JUMP (P4)

   4 Target : <0xffa007b0> { _trap + 0x0 }

      FAULT : <0x02ea7196> [ ephone + 0x7156 ] [P2++] = R0

     Source : <0x02ea7194> [ ephone + 0x7154 ] W[P6 + 7] = R0

   5 Target : <0x02ea7192> [ ephone + 0x7152 ]

     Source : <0x02ea7114> [ ephone + 0x70d4 ] IF !CC JUMP pcrel (BP)

   6 Target : <0x02ea7112> [ ephone + 0x70d2 ]

     Source : <0x02ea7b58> [ ephone + 0x7b18 ] RTS

   7 Target : <0x02ea7b4c> [ ephone + 0x7b0c ]

     Source : <0x02ea7110> [ ephone + 0x70d0 ] CALL (P2)

   8 Target : <0x02ea70fe> [ ephone + 0x70be ]

     Source : <0x02ea749e> [ ephone + 0x745e ] RTS

   9 Target : <0x02ea7498> [ ephone + 0x7458 ]

     Source : <0x02ea748c> [ ephone + 0x744c ] JUMP.S

  10 Target : <0x02ea7480> [ ephone + 0x7440 ]

     Source : <0x02ea7460> [ ephone + 0x7420 ] IF !CC JUMP pcrel (BP)

  11 Target : <0x02ea7452> [ ephone + 0x7412 ]

     Source : <0x02ea7494> [ ephone + 0x7454 ] IF !CC JUMP pcrel (BP)

  12 Target : <0x02ea7492> [ ephone + 0x7452 ]

     Source : <0x02ea7450> [ ephone + 0x7410 ] JUMP.S

  13 Target : <0x02ea7434> [ ephone + 0x73f4 ]

     Source : <0x02ea70fa> [ ephone + 0x70ba ] CALL pcrel

  14 Target : <0x02ea70ee> [ ephone + 0x70ae ]

     Source : <0x02ea7b58> [ ephone + 0x7b18 ] RTS

  15 Target : <0x02ea7b4c> [ ephone + 0x7b0c ]

     Source : <0x02ea70ec> [ ephone + 0x70ac ] CALL (P2)

Userspace Stack

Stack info:

SP: [0x02eb3b44] <0x02eb3b44> [ ephone + 0x13b44 ]

FP: (0x02eb3b3c)

Memory from 0x02eb3b40 to 02eb4000

02eb3b40:<02ea7112>[00000000] 00000000  00000000  00000000  00000000  00000000

02eb3b60: 02eb3b9c  02ea56a0 <02ead108> 00000241  00000000  02eb3bb4  02ea70b4

02eb3b80: 00000110  00000000  00000000  02eb3b90  00000000  00000000  00000000

02eb3ba0: 02ea552a  02eb2260  02eb2234  02eac4c8  02eb1124  00000000  02eb112c

02eb3bc0: 02ea75ee  02eb1124  ffffffff  02eb3be4  02ea3962  02eb3bf8  00000000

02eb3be0: 02eb3c18  02eb3c18  02ea300a  02eb2260  02eb2234  02eac4c8  02eb1124

02eb3c00: 02eb112c  00000000  00000000  02eb3c2c  02ea9b58  02eb3fee  02eb3c48 >

02eb3c20: 00000000  00000001  02eb13c0  00000000  02eb3c8c  02eac250  02ea2c5c

02eb3c40: 02eb3c8c  00000000  00000000  02ec1f94  02eac2a0  02ba37e4  02edb35c

02eb3c60: 0000000c  00000002  02ede54c  00000000  00000000  00000000  02eac250

02eb3c80: 00000000  02eeec1c  00000001  02eb3cf1  00000000 <02eb3cfa> 02eb3d1c

02eb3ca0: 02eb3d5c  02eb3d76  02eb3d85  02eb3d93  02eb3de3  02eb3e07 <02eb3e2a>

02eb3cc0:<02eb3e90> 02eb3ec3  02eb3ed7  02eb3ef1  02eb3f0d  02eb3f26 <02eb3f42>>

02eb3ce0: 02eb3f7a  02eb3f8b  02eb3fdf  00000000  652f2e00  6e6f6870  41500065

02eb3d00: 3a6e6962  7273752f  6e69622f  73752f3a  6f6c2f72  2f6c6163  006e6962

02eb3d20: 535f5245  5754464f  3d455241  2f616f42  34392e30  7234312e  00313263

02eb3d40: 4e5f5245  3d454d41  2e777777  622d474c  6b63616c  2e6e6966  006d6f63

02eb3d60: 5f594157  45544e49  43414652  47433d45  2e312f49  45530031  52455652

02eb3d80: 30383d54  52455300  5f524556  494d4441  48003d4e  5f505454  52455355

02eb3da0: 4d3d544e  6c697a6f  352f616c  2820302e  646e6957  2073776f  3520544e

02eb3dc0: 353a7672  2029302e  6b636547  30322f6f  31303031  46203130  66657269

02eb3de0: 4800302e  5f505454  45434341  4c5f5450  55474e41  3d454741  752d6e65

02eb3e00: 303d713b  4800352e  5f505454  45434341  455f5450  444f434e  3d474e49

02eb3e20: 6564202c  74616c66  54480065  415f5054  50454343  48435f54  45535241

02eb3e40: 38382d4f  312d3935  6674752c  713b382d  372e303d  713b2a2c  372e303d

02eb3e60: 45525f50  45524546  74683d52  2f3a7074  3239312f  3836312e  3030312e

02eb3e80: 6967632f  6e69622d  6870652f  00656e6f  50545448  4645525f  52455245

02eb3ea0: 2f2f3a70  2e323931  2e383631  2e303031  2f303331  2d696763  2f6e6962

02eb3ec0: 5200656e  45555145  4d5f5453  4f485445  4f503d44  48005453  5f505454

02eb3ee0: 3239313d  3836312e  3030312e  3033312e  52455300  5f524556  52444441

02eb3f00: 3836312e  3030312e  3033312e  52455300  5f524556  544f5250  4c4f434f

02eb3f20: 2e312f50  45520031  53455551  52555f54  632f3d49  622d6967  652f6e69

02eb3f40: 43530065  54504952  4d414e5f  632f3d45  622d6967  652f6e69  6e6f6870

02eb3f60: 45544f4d  4444415f  39313d52  36312e32  30312e38  31312e30  45520037

02eb3f80: 524f505f  34343d54  43003538  45544e4f  545f544e  3d455059  746c756d

02eb3fa0: 6f662f74  642d6d72  3b617461  756f6220  7261646e  2d2d3d79  2d2d2d2d

02eb3fc0: 2d2d2d2d  2d2d2d2d  2d2d2d2d  2d2d2d2d  3939312d  33313436  36353034

02eb3fe0: 45544e4f  4c5f544e  54474e45  32313d48  2e003533  6870652f  00656e6f

Return addresses in stack:

    address : <0x02ea7112> [ ephone + 0x70d2 ]

    address : <0x02ead108> [ ephone + 0xd108 ]

    address : <0x02ea7cdc> [ ephone + 0x7c9c ]

    address : <0x02eb3cfa> [ ephone + 0x13cfa ]

    address : <0x02eb3e2a> [ ephone + 0x13e2a ]

    address : <0x02eb3e90> [ ephone + 0x13e90 ]

    address : <0x02eb3f42> [ ephone + 0x13f42 ]

    address : <0x02eb3f5e> [ ephone + 0x13f5e ]

 

root:/etc>

root:/etc>

QuoteReplyEditDelete

 

 

2011-07-21 10:11:27     Re: NULL pointer access - BOA and CGIC to file upload

Mike Frysinger (UNITED STATES)

Message: 102598   

 

boa is not an ftp server, nor is it a client.  the transfer type is something the client negotiates.

 

what the app does when executed really doesnt matter.  as soon as you overflow your stack, all bets are off.

QuoteReplyEditDelete

 

 

2011-07-21 13:07:26     Re: NULL pointer access - BOA and CGIC to file upload

wag hanna (UNITED STATES)

Message: 102601   

 

Hi Mike,

 

Are you suggesting to try building the code as FDPIC ELF format? I have zero experience with file formats and don't understand how BOA interacts with a *FTP* server to receive the file being sent by the client. The BOA error and access logs don't show any trace of the interaction with the FTP server, so I'm a bit at a loss here...

 

Could you point me to the next logical step to determine the issue with file uploading?

 

 

 

thanks

QuoteReplyEditDelete

 

 

2011-07-21 13:37:01     Re: NULL pointer access - BOA and CGIC to file upload

Mike Frysinger (UNITED STATES)

Message: 102602   

 

please read the document i already posted.  it tells you how to increase the stack size on FLAT binaries.

QuoteReplyEditDelete

 

 

2011-07-22 00:53:34     Re: NULL pointer access - BOA and CGIC to file upload

Wojtek Skulski (UNITED STATES)

Message: 102609   

 

wag, concerning ftp and how it relates to boa. I found the following statement in some app note. Perhaps it will lead you to the solution.

 

Many basic network services (including telnet and ftp) do not register as an individual service but are started by inetd, the Internet daemon. These services are enabled or disabled by editing the file /etc/inetd.conf (when using the original inetd) or the files in the /etc/xinetd.x directory (when using the newer xinetd, the extended Internet daemon).

QuoteReplyEditDelete

Attachments

    Outcomes