Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#17751 closed bug (fixed)

`write` and similar calls allows reading from allocated but protected memory.

Reported by: trungnt2910 Owned by: nobody
Priority: normal Milestone: R1/beta4
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

    const int size = 4096;
    void* ptr = mmap(nullptr, size, PROT_NONE, MAP_ANON | MAP_PRIVATE, -1, 0);
    // Crashes
    // std::cout << "Pointer value is: " << std::flush << *(int*)ptr << std::endl;
    // Still returns 1, expected -1
    std::cout << write(fds[1], ptr, 1) << std::endl;
    // false, expected true
    std::cout << std::boolalpha << (errno == EFAULT) << std::noboolalpha << std::endl;

Some portable libraries targeting POSIX is using the write function and write to a dummy pipe to check if a range of memory is accessible.

For non-accessible memory (either unallocated or protected), the function should return -1 and set errno to EFAULT .

On Haiku, this works well for unallocated memory, but not for protected memory. Therefore, the code snippet above doesn't run as expected.

The full code is attached to this ticket.

Attachments (1)

test.cpp (1.1 KB ) - added by trungnt2910 3 years ago.
Minimal C++ program for testing this bug

Download all attachments as: .zip

Change History (6)

by trungnt2910, 3 years ago

Attachment: test.cpp added

Minimal C++ program for testing this bug

comment:1 by waddlesplash, 3 years ago

Component: System/POSIXSystem/Kernel

comment:2 by waddlesplash, 3 years ago

Milestone: UnscheduledR1/beta4
Resolution: fixed
Status: newclosed

Fix merged in hrev56131. Thanks for working on this!

comment:3 by kim1963, 3 years ago

Reopened.

hrev56131 - no boot !!!!!!!!!!!!!!!!!!!!!!!!!!

Last edited 3 years ago by kim1963 (previous) (diff)

comment:4 by korli, 3 years ago

We might well revert and only apply first the changes in the drivers and go from there.

comment:5 by waddlesplash, 3 years ago

At least one KDL, in SATA/AHCI, was already reported via IRC. I will fix that today, it's possible whatever kim1963 is seeing is the same. New tickets should be opened however, not reopening old ones.

Note: See TracTickets for help on using tickets.