linux-kernel - Re: [PATCH AUTOSEL 5.1 058/186] tracing: probeevent: Fix to make the type of $comm string

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190609191337.GA1552@sasha-vm>
Date:   Sun, 9 Jun 2019 15:13:37 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Andreas Ziegler <andreas.ziegler@....de>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH AUTOSEL 5.1 058/186] tracing: probeevent: Fix to make the
 type of $comm string

On Sat, Jun 08, 2019 at 05:31:13PM -0400, Steven Rostedt wrote:
>On Sat,  1 Jun 2019 09:14:34 -0400
>Sasha Levin <sashal@...nel.org> wrote:
>
>> From: Masami Hiramatsu <mhiramat@...nel.org>
>>
>> [ Upstream commit 3dd1f7f24f8ceec00bbbc364c2ac3c893f0fdc4c ]
>>
>> Fix to make the type of $comm "string".  If we set the other type to $comm
>> argument, it shows meaningless value or wrong data. Currently probe events
>> allow us to set string array type (e.g. ":string[2]"), or other digit types
>> like x8 on $comm. But since clearly $comm is just a string data, it should
>> not be fetched by other types including array.
>>
>> Link: http://lkml.kernel.org/r/155723736241.9149.14582064184468574539.stgit@devnote2
>>
>> Cc: Andreas Ziegler <andreas.ziegler@....de>
>> Cc: Ingo Molnar <mingo@...hat.com>
>> Cc: stable@...r.kernel.org
>> Fixes: 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code")
>
>I thought the "AUTOSEL" patches are to find patches that are not marked
>for stable and pull them in. It would be good to differentiate those in
>the subject. As I'm more inclined to audit automatically pulled in ones,
>because those are more likely to be incorrectly backported.

That's indeed the case. I had some experimental changes for this merge
window and apparently some stable tagged patches ended up sneaking in.
Sorry about that!.

--
Thanks,
Sasha