flink() at last?

Posted Aug 13, 2013 15:07 UTC (Tue) by idle (guest, #5017)
In reply to: flink() at last? by spender
Parent article: flink() at last?

> The main point was the complete absence of any mention of
> security impact in the commit message

Well, the changelog explains that we leak the memory. Doesn't
this obviously mean the bad impact?

I do not think that the fact it was reported via oss-sec list
does matter, the bug is bug. In fact I didn't even notice this
list in CC.

But. I am really sorry I didn't add Reported-by tag, seriously.
This is only because I didn't know whom should we thank. I sent
the patch for review and I specially asked about the reporter,
but the patch was merged immediately and I could not update the
changelog.

flink() at last?

Posted Aug 13, 2013 15:41 UTC (Tue) by spender (guest, #23067) [Link] (1 responses)

Does it? There are no matches for either "leak" or "memory" in the commit message.

There is only vague mention of unspecified "side effects" that need "taking care of" in response to a function failure. Failures can be of the unfailable kmalloc+GFP_KERNEL kind, after all. I wonder how anyone, not already knowing about the CVE and public disclosure from elsewhere, would have any clue what the impact of that fix is.

Are you really trying to say the commit message was written with clarity and transparency of the impact of the fix in mind, without some Linus-enforced brain filter on what words you're allowed to use to describe the "bug"?

-Brad

flink() at last?

Posted Aug 13, 2013 16:07 UTC (Tue) by idle (guest, #5017) [Link]

> Does it? There are no matches for either "leak" or "memory"
> in the commit message.

I thought that "take care of" should be clear enough, and it
mentions put_cred().

> There is only vague mention of unspecified "side effects"

This just tries to explain why the patch didn't change the
caller instead, the patch would be even simpler.

> Are you really trying to say the commit message was written
> with clarity and transparency of the impact of the fix in mind

OK. When I reread it I agree, it could be more clear. Trust me,
this was not intentional. I did not try to "hide" the fact this
patch fixes the easily triggable memory leak.

It would be just silly, exactly because it was not me who founf
the bug!

> Linus-enforced brain filter on what words you're allowed to
> use to describe the "bug"?

What are you talking about ;) Nobody will ever try to force you
obfuscate the changelog.