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) <[email protected]> Signed-off-by: Samuel Price <[email protected]> -- 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
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
