https://bugs.kde.org/show_bug.cgi?id=514297
--- Comment #22 from Mark Wielaard <[email protected]> --- (In reply to mcermak from comment #19) > Created attachment 190342 [details] > proposed patch Sorry Comment #20 was in response to your earlier patch. But most of it applies to this one too. You still need to use VG_(safe_fd) for the cl_pagemap_fd. It would be better if cl_pagemap_fd was only defined/used in coregrind/m_aspacemgr/aspacemgr-linux.c You could set it up in VG_(am_startup). I think we should avoid that ../pub_core_clientstate.h include. And ideally (IMHO) it would only be used for sanity checks (--sanity-level=3 testing). It might be simpler (less duplicate code) to have just notify_madv_guard ( Addr start, SizeT len, Bool install ) and notify_core_and_tool_of_madv_guard ( Addr a, SizeT len, Bool install ) Where the remove is when install == False. Technically only on install do we needDiscard (when removing the guard page no code could have been there). notify_core_and_tool_of_madv_guard should be called in the POST(sys_madvise) handler not in the PRE handler (we don't know if madvise succeeds till after the syscall returns). I think the safe_to_deref before the PRE_MEM_RASCIIZ might be a separate/generic issue. Lets not forget about it, but it might not need to go into this patch. > The attached patch seems to work fine not only with my synthetic reproducer, > but also with real life scenarios on Fedora-44. Example ways to trick glibc > into installing a guard page: > > - dnf makecache > - curl -s http://sourceware.org -o /dev/null Could you show how these programs use the guard pages ? Could you investigate how things work with memcheck/tests/descr_belowsp.vgtest ? -- You are receiving this mail because: You are watching all bug changes.
