RTEMS | Draft: testsuites/fstests: Add fsjffs2unmount01 (!1440)

[Sam Price (@TheSamPrice)]

Sam Price created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1440

Project:Branches: TheSamPrice/rtems:test/jffs2-unmount-heap to rtems/rtos/rtems:main
Author:   Sam Price



GCC's -fanalyzer reports a use after free and a double free of root_i on
the JFFS2 unmount path, at cpukit/libfs/src/jffs2/src/fs-rtems.c:1093 and
:1098, where jffs2_iput(root_i) is followed by
rtems_jffs2_free_directory_entries(root_i) and free(root_i).

Whether that is real turns on the root inode's link count, since
jffs2_iput frees only when i_count reaches zero and i_nlink is also zero,
and the assert above the call fixes i_count at 1.  Reading the code does
not settle it.

fsjffs2empty01 already mounts and unmounts twice, but a passing exit
status does not show the heap is intact: freeing a block twice need not
fault if the block is not reused, and jffs2_iput poisons with 0x5a before
freeing, so a use after free can read plausible garbage.

This checks the heap instead.  Nine mount and unmount cycles, malloc_walk
after each, which fails on the corrupted free lists a double free
produces, and malloc_info compared across cycles, which grows if the free
never happens.  Both failure modes are covered, so a pass is evidence
rather than an absence of symptoms.

Measured on riscv/mbv: malloc_walk clean every cycle, and 336 bytes in 4
blocks both after the first cycle and after the ninth.

Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
Signed-off-by: Samuel Price <thesamprice at gmail.com>

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1440
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-bibcguux3b6fxwze3pahm2s1a-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260821/1bb23ae0/attachment.htm>