[BUG] Crash in setenv with Invalid Pointer

[Rrooach]

Description / Steps to reproduce the issue

When using the setenv function in NuttX, I encountered a potential issue where the function crashes if an invalid or inaccessible pointer is passed to the value parameter. Specifically:

When calling my_setenv(0x8001, 0x0, 0x9), the program runs without any issues. However, when calling my_setenv(0x7, 0x5, 0x8), the program crashes.

Use the following code:

static long my_setenv(volatile long name_ptr, volatile long value_ptr, volatile long overwrite)
{
    const char *name = (const char *)name_ptr;
    const char *value = (const char *)value_ptr;
    return (long)setenv(name, value, (int)overwrite);
}

int main(int argc, FAR char *argv[])
{
    printf("CPU0: Beginning Idle Loop\n");
    executor_check_ints();
    my_setenv(0x8001, 0x0, 0x9);  // Runs without error
    my_setenv(0x7, 0x5, 0x8);     // Crashes here
    printf("CPU0: Finish\n");  
}

Compile and run the program using:

cmake -B build_new4 -DBOARD_CONFIG=rv-virt:nsh64  -GNinja
cmake --build build_new4 -t clean && cmake --build build_new4

run using

qemu-system-riscv64 -semihosting -M virt,aclint=on -cpu rv64 -smp 8 -bios none -kernel /root/HJ/nuttx/nuttx-nocov/build_new4/nuttx -nographic

Then the program keeps crashing.

Using GDB, I traced the issue to the following line in setenv:

if (!value || !value[0])

When value=0x5, the program attempts to dereference an inaccessible memory address, resulting in a crash. It seems the pointer is dereferenced without first checking whether it is valid or accessible.

To handle such cases more robustly, the function could validate the accessibility of the value pointer before dereferencing it. For example, using access_ok() might help ensure the pointer is valid.

On which OS does this issue occur?

[OS: Linux]

What is the version of your OS?

Debian GNU/Linux 12 (bookworm)

NuttX Version

fc993539aa

Issue Architecture

[Arch: risc-v]

Issue Area

[Area: Kernel]

Verification

• I have verified before submitting the report.

[acassis]

@Rrooach Good finding! NuttX doesn't have the access_ok() macro yet, searching for it I found mpfs_mpu_access_ok() :-)

[acassis]

@xiaoxiang781216 what do you think?

[Rrooach]

@Rrooach Good finding! NuttX doesn't have the access_ok() macro yet, searching for it I found mpfs_mpu_access_ok() :-)

Hi @acassis,

Thank you for your timely and nice responses!

While debugging this issue, I noticed that access_ok() does not seem to be available in NuttX, which made it difficult for me to suggest a proper fix for this problem.

Additionally, as part of our work, we have been fuzzing NuttX and have encountered some more errors. However, we are unsure how to report these issues to the Nuttx community in a way that is both effective and minimally disruptive to the community and developers.

Also, after discussing with my supervisor, we are happy to provide the fuzzer we developed to help the community ensure a safer and more robust NuttX. Please let us know if this would be helpful or if there are any specific guidelines for contributing these tools or related findings.

Thank you again for your support!

Best regards,

[acassis]

Hi @Rrooach,
you need to follow the ASF vulnerabilities disclosure: https://www.apache.org/security/

That is a great news, having the fuzzer you developed to help make NuttX safer and more robust will be very helpful. Thank you very much for doing that!