[RTEMS Project] #1625: TFTPFS memory corruption using relative paths

[RTEMS trac]

#1625: TFTPFS memory corruption using relative paths
---------------------------+-----------------------
 Reporter:  angus.gratton  |       Owner:  chrisj
     Type:  defect         |      Status:  assigned
 Priority:  normal         |   Milestone:  4.10.3
Component:  filesystem     |     Version:  4.10
 Severity:  normal         |  Resolution:
 Keywords:                 |
---------------------------+-----------------------
Changes (by gedare):

 * milestone:  4.10 => 4.10.3


Old description:

> This is an issue I experienced when using 'chdir' and relative path
> access on TFTPFS in RTEMS 4.10.
>
> Again, I was using a PowerPC MVME3100 but I think this is non-
> architecture-specific.
>
> You may need to apply the patches submitted with Bug 1624 before you can
> get to this point at all (absolute path TFTPFS should be working as a
> prerequisite.)
>
> To reproduce, use the attached test.c in place of network-
> demos/tftpTest/test.c and run the tftpTest program. You will see the
> initial absolute path accesses succeed, then the chdir & the first
> relative path access succeed, but the second relative path access will
> fail. You'll probably see a double-free error at this point.
>
> The problem is that the pathloc->node_access pointer value is saved in
> the 'rtems_current_directory' struct, but it is also freed by the
> rtems_ftp_free_node_info() function. So the next TFTPFS access that uses
> a relative path will read unallocated memory.
>
> I've attached a somewhat hacky patch that fixes this specific case, and
> helps to demonstrate the issue.
>
> I don't think this is actually the "correct" way to fix the problem
> though, as it relies on each FS implementation explicitly checking if it
> is freeing the 'current_directory' copy of any pointers.
>
> I think a better fix would be to implement a
> rtems_filesystem_dup_node_info() function for each filesystem, where the
> FS itself allocates new copies of any heap-allocated resources. Then the
> filesystem layer can call dup_node_info before writing the copy to the
> rtems_current_directory value, ensuring it has its own unique version of
> any heap-allocated resources.
>
> I didn't have time to implement that though, sorry - need to get EPICS up
> and running!
>
> Please let me know if you need me to explain anything better - the test
> app & patch should be more instructive than my vague rantings.

New description:

 This is an issue I experienced when using 'chdir' and relative path access
 on TFTPFS in RTEMS 4.10.
 Again, I was using a PowerPC MVME3100 but I think this is non-
 architecture-specific.
 You may need to apply the patches submitted with Bug 1624 before you can
 get to this point at all (absolute path TFTPFS should be working as a
 prerequisite.)
 To reproduce, use the attached test.c in place of network-
 demos/tftpTest/test.c and run the tftpTest program. You will see the
 initial absolute path accesses succeed, then the chdir & the first
 relative path access succeed, but the second relative path access will
 fail. You'll probably see a double-free error at this point.
 The problem is that the pathloc->node_access pointer value is saved in the
 'rtems_current_directory' struct, but it is also freed by the
 rtems_ftp_free_node_info() function. So the next TFTPFS access that uses a
 relative path will read unallocated memory.
 I've attached a somewhat hacky patch that fixes this specific case, and
 helps to demonstrate the issue.
 I don't think this is actually the "correct" way to fix the problem
 though, as it relies on each FS implementation explicitly checking if it
 is freeing the 'current_directory' copy of any pointers.
 I think a better fix would be to implement a
 rtems_filesystem_dup_node_info() function for each filesystem, where the
 FS itself allocates new copies of any heap-allocated resources. Then the
 filesystem layer can call dup_node_info before writing the copy to the
 rtems_current_directory value, ensuring it has its own unique version of
 any heap-allocated resources.
 I didn't have time to implement that though, sorry - need to get EPICS up
 and running!
 Please let me know if you need me to explain anything better - the test
 app & patch should be more instructive than my vague rantings.

--

--
Ticket URL: <http://devel.rtems.org/ticket/1625#comment:6>
RTEMS Project <http://www.rtems.org/>
RTEMS Project