On Thu, Sep 23, 2021 at 07:13:06PM -0700, Andrew Morton wrote: > On Thu, 23 Sep 2021 16:31:05 -0700 Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > > The /proc/$pid/wchan file has been broken by default on x86_64 for 4 > > years now[1]. > > [1] is hard to decrypt. I think it would be better if this changelog > were to describe the problem directly, completely and succinctly? > > > As this remains a potential leak of either kernel > > addresses (when symbolization fails) or limited observation of kernel > > function progress, just remove the contents for good. > > > > Unconditionally set the contents to "0" and also mark the wchan > > field in /proc/$pid/stat with 0. > > > > This leaves kernel/sched/fair.c as the only user of get_wchan(). But > > again, since this was broken for 4 years, was this profiling logic > > actually doing anything useful? > > Agree that returning a hard-wired "0\n" is the way to go. I must NAK my own patch. ;) It looks like this would be a breaking userspace-visible change[1]. We need to fix the two bugs though: 1) wchan broken under ORC (patch exists in the thread at [1]) 2) wchan leaking raw addresses (152c432b128c needs reverting from v5.12 and later) -Kees [1] https://lore.kernel.org/lkml/20210924054647.v6x6risoa4jhuu6s@xxxxxxxxxxxxxxxxxxxxxxxx -- Kees Cook
