Date: Tue, 30 Jan 2024 20:30:23 +0000 From: bugzilla-noreply@freebsd.org To: riscv@FreeBSD.org Subject: [Bug 273438] PANIC: memory modified after free on relatively idle riscv -CURRENT Message-ID: <bug-273438-40250-ENJNRzvHAQ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-273438-40250@https.bugs.freebsd.org/bugzilla/> References: <bug-273438-40250@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273438 Mitchell Horne <mhorne@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #8 from Mitchell Horne <mhorne@freebsd.org> --- (In reply to Mitchell Horne from comment #7) Okay I spoke too soon re: the offset; it is trivially calculated as 0x908 - 0x7f8 =3D 0x188 =3D 392. According to gdb, the struct dmu_buf_impl member a= t offset 392, for your revision, is db_user, an 8 byte pointer.=20 The expected contents of uninitialized memory is 0xdeadc0deadc0de, but your reports consistently show the affected address as 0x00000000de00c0de. So it= is only partially overwritten, and therefore not an abuse of the db_user field= in a dmu_buf_impl_t object. So, I'm thinking this allocation missed the zone's cache (empty), and the memory could have belonged to anything before that, meaning use-after-free could exist anywhere...=20 I'll have to see what other tips I can learn to help identify this. On other platforms we could use KASAN, but for riscv it is not implemented yet. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273438-40250-ENJNRzvHAQ>