https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231080
--- Comment #17 from Mark Johnston <ma...@freebsd.org> ---
(In reply to Sean Bruno from comment #16)
The new kernel dump is more useful. The callout looks like this:
$2 = {
c_links = {
le = {
le_next = 0x11777be9162acbc1,
le_prev = 0xffffffff80c9a01a
},
sle = {
sle_next = 0x11777be9162acbc1
},
tqe = {
tqe_next = 0x11777be9162acbc1,
tqe_prev = 0xffffffff80c9a01a
}
},
c_time = 577765376,
c_precision = 0,
c_arg = 0x6,
c_func = 0x158,
c_lock = 0x0,
c_flags = 0,
c_iflags = 0,
c_cpu = 0
}
(kgdb) x/s 0xffffffff80c9a01a
0xffffffff80c9a01a: "dr->dt.di.dr_mtx"
So the second long word is the beginning of the dr_mtx field of a
dbuf_dirty_record_t. (The 0x6 indicates that the lock is already destroyed.)
It thus looks like the structure containing the callout was freed and
reused for a dbuf_dirty_record_t. These records are allocated using malloc(9)
and would come from the 512 byte zone (the mutex is at byte offset 192), so
we're looking for a structure between 256 and 512 bytes in size containing
a struct callout at byte offset 184, assuming that nothing called uma_reclaim()
before the dbuf_dirty_record_t was allocated. Since there's been very little
page daemon activity on this system, I think that's a safe assumption for now.
Using ctfdump -t on the kernel and modules, I find two structures with these
properties: struct ata_request and struct lle_entry. The latter seems to be a
more likely candidate for use-after-free.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
