Soundness bug using Cursor::iter_from()

I ran into a soundness bug by letting an iterator outlive the underlying cursor. In my safe code, I created an iterator using Cursor::iter_from. When Cursor::iter_from returned, the ffi::MDB_cursor got deallocated (during unsafe RoCursor::drop) but the pointer to it was retained inside the iterator that was returned in Cursor::iter_from while my safe code was iterating. That caused the soundness bug when after several successful iterations an unrelated part of the program wrote at that address.

Links to the code:

lmdb-rs/src/cursor.rs

Line 78 in 4363ec0

fn iter_from<K>(&mut self, key: K) -> Iter<'txn>

lmdb-rs/src/cursor.rs

Line 33 in 4363ec0

fn cursor(&self) -> *mut ffi::MDB_cursor;

lmdb-rs/src/cursor.rs

Line 148 in 4363ec0

unsafe { ffi::mdb_cursor_close(self.cursor) }

I would add unsafe to Cursor::iter_from but I understand that this could cause a lot of changes to the API, so another idea may be better.

I think I am getting this error too, and that it's related to #25 & #5

I also encountered this problem I think about a year ago in danburkert/lmdb-rs, when trying to return a rust iterator type wrapping the lmdb one, from a database abstraction layer object. It segfaulted a lot and I was never able to debug it, and eventually gave up and backed out of that idea. Thank you for explaining :)