Modify

Ticket #5900 (closed Bugs: fixed)

Opened 3 years ago

Last modified 2 years ago

Access violation in boost filesystem 3 directory iterator

Reported by: Andreas Eckleder <a.eckleder@…> Owned by: bemandawes
Milestone: Boost 1.49.0 Component: filesystem
Version: Boost 1.47.0 Severity: Problem
Keywords: Cc:

Description

Whenever dir_itr_increment() reports an error (e.g. because an error code was returned by FindNextFile?() on WIN32), directory_iterator_increment() will crash with an access violation when trying to throw a filesystem error.

The access violation is caused by an attempt to read the parent path string from it.m_imp immediately after calling it.m_imp.reset().

Please find a patch against boost 1.47.0 attached to this ticket. It fixes the issue without any side-effects by storing the parent path locally before calling it.m_imp.reset().

The issue is hard to reproduce as essentially a defective file-system is required to see its effect. However, I think it should be sufficiently clear from the patch what's going on. I ran across this when trying to read from an optical disc with a defective UDF file-system.

Attachments

directory_iterator.patch Download (882 bytes) - added by Andreas Eckleder <a.eckleder@…> 3 years ago.
Patch fixing a potential access violation when trying to read defective directories / directories for which windows replies with an error code in FindNextFile?().

Change History

Changed 3 years ago by Andreas Eckleder <a.eckleder@…>

Patch fixing a potential access violation when trying to read defective directories / directories for which windows replies with an error code in FindNextFile?().

comment:1 Changed 2 years ago by anonymous

We ran into the same problem on OSX, when a directory was deleted while we were in the middle of iterating over it. Note that if you don't want to or can't change the source to Boost as per the patch above, simply passing in an error_code to directory_iterator::increment() will circumvent the bug, since the bad dereference is buried in the exception creation.

comment:2 Changed 2 years ago by anonymous

I was wrong in my previous comment stating that there was a work-around without changing the source to Boost. There's a second bug that stops this from working. directory_iterator_construct() does not pass the error code to "increment", so even if an error code is passed into directory_iterator_construct(), when it gets into directory_iterator_increment() the error code will be lost and the exception will trigger.

comment:3 Changed 2 years ago by bemandawes

  • Status changed from new to assigned

I'm working Filesystem bugs right now. I'll work this one tomorrow or the next day.

Thanks,

--Beman

comment:4 Changed 2 years ago by bemandawes

  • Status changed from assigned to closed
  • Resolution set to fixed
  • Milestone changed from To Be Determined to Boost 1.49.0

Both the original bug and the bug reported in comment 3 have been fixed.

Thanks for the reports and the patch!

--Beman

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.