Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#16058 closed bug (fixed)

_kern_read_link changes cause ls to crash

Reported by: waddlesplash Owned by: ambroff
Priority: blocker Milestone: R1/beta2
Component: System Version: R1/Development
Keywords: Cc: ambroff
Blocked By: Blocking:
Platform: All

Description

  1. Run ls -alR /system/add-ons
  2. Crash!

This is with coreutils-8.29-2 (i.e. the version that we have been bundling with Haiku since over a month ago.)

I'm not sure if this was always present on this version, or nobody noticed until now. Either way, seems serious enough to be a blocker.

Attachments (2)

ls-2455-debug-17-05-2020-23-53-17.report (7.6 KB ) - added by waddlesplash 5 years ago.
ls-2040-debug-18-05-2020-00-00-50.report (7.3 KB ) - added by waddlesplash 5 years ago.

Download all attachments as: .zip

Change History (13)

by waddlesplash, 5 years ago

comment:1 by waddlesplash, 5 years ago

(I had a libroot in non-packaged with rpmalloc; the equivalent assert in hoard2 occurs also.)

Multiple users on IRC reported this, and it reproduces in a fresh build of both x86_64 and x86_gcc2h.

by waddlesplash, 5 years ago

comment:2 by waddlesplash, 5 years ago

For some reason, it does not reproduce with the guarded heap. With the debug heap:

        state: Call (someone wrote beyond small allocation at 0x180062d0; size: 0 bytes; allocated by 0; value: 0x0000002e

comment:4 by waddlesplash, 5 years ago

Cc: ambroff added

CC ambroff: your readlink change looks notable. Checking to see if that is the culprit now...

comment:5 by waddlesplash, 5 years ago

Component: - GeneralSystem
Owner: changed from nobody to ambroff
Status: newassigned
Summary: ls crashes_kern_read_link changes cause ls to crash

Reverting hrev54107 fixed the crash. ambroff, can you please take a look? At worst we could revert this in the beta branch, but a proper fix would indeed be nice.

comment:6 by ambroff, 5 years ago

Dang, thanks for reverting waddlesplash. I'll look into it today or tomorrow if time permits.

comment:7 by korli, 5 years ago

I took a deeper look:

Not related, shouldn't rootfs and devfs readlink behavior also changed? https://github.com/haiku/haiku/blob/master/src/system/kernel/fs/rootfs.cpp#L862 https://github.com/haiku/haiku/blob/master/src/system/kernel/device_manager/devfs.cpp#L1180

The checksumfs looks also to be changed: https://github.com/haiku/haiku/blob/master/src/tests/system/kernel/file_corruption/fs/SymLink.cpp#L62

The write_overlay looks also to be changed: https://github.com/haiku/haiku/blob/master/src/add-ons/kernel/file_systems/layers/write_overlay/write_overlay.cpp#L1062

Also vfs null-terminates on success, this looks not OK (size should be checked against B_PATH_NAME_LENGTH at least) https://github.com/haiku/haiku/blob/master/src/system/kernel/fs/vfs.cpp#L2252 https://github.com/haiku/haiku/blob/master/src/system/kernel/fs/vfs.cpp#L2956

_user_read_link behavior is now bad, it will write after the buffer end, anytime the buffer is too short. It should honor the user bufferSize, instead of using the link length. https://github.com/haiku/haiku/blob/master/src/system/kernel/fs/vfs.cpp#L9418

comment:8 by waddlesplash, 5 years ago

korli's changes merged in hrev54234. I did not retest if this fixes the problem though.

comment:9 by korli, 5 years ago

yes it fixes the problem in master. I added https://review.haiku-os.org/c/haiku/+/2761 to expose the symlink string length in package nodes (this would have been a workaround for the bug).

Last edited 5 years ago by korli (previous) (diff)

comment:10 by waddlesplash, 5 years ago

Resolution: fixed
Status: assignedclosed

comment:11 by ambroff, 5 years ago

Thank you korli for looking at this and fixing all of these issues that I left dangling. Sorry that I took so long. I've been busy the last couple of days.

Note: See TracTickets for help on using tickets.