Opened 5 weeks ago

Closed 5 weeks ago

Last modified 5 weeks 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 5 weeks ago.
Minimal C++ program for testing this bug

Download all attachments as: .zip

Change History (6)

by trungnt2910, 5 weeks ago

Attachment: test.cpp added

Minimal C++ program for testing this bug

comment:1 by waddlesplash, 5 weeks ago

Component: System/POSIXSystem/Kernel

comment:2 by waddlesplash, 5 weeks ago

Milestone: UnscheduledR1/beta4
Resolution: fixed
Status: newclosed

Fix merged in hrev56131. Thanks for working on this!

comment:3 by kim1963, 5 weeks ago

Reopened.

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

Last edited 5 weeks ago by kim1963 (previous) (diff)

comment:4 by korli, 5 weeks ago

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

comment:5 by waddlesplash, 5 weeks 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.