[lkml]   [2021]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/3] Fix some seq_file users that were recently broken
On Fri, Feb 05 2021, Andrew Morton wrote:

> On Fri, 05 Feb 2021 11:36:30 +1100 NeilBrown <> wrote:
>> A recent change to seq_file broke some users which were using seq_file
>> in a non-"standard" way ... though the "standard" isn't documented, so
>> they can be excused. The result is a possible leak - of memory in one
>> case, of references to a 'transport' in the other.
>> These three patches:
>> 1/ document and explain the problem
>> 2/ fix the problem user in x86
>> 3/ fix the problem user in net/sctp
> 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and
> interface") was August 2018, so I don't think "recent" applies here?

I must be getting old :-(

> I didn't look closely, but it appears that the sctp procfs file is
> world-readable. So we gave unprivileged userspace the ability to leak
> kernel memory?

Not quite that bad. The x86 problem allows arbitrary memory to be
leaked, but that is in debugfs (as I'm sure you saw) so is root-only.
The sctp one only allows an sctp_transport to be pinned. That is not
good and would, e.g., prevent the module from being unloaded. But
unlike a simple memory leak it won't affect anything outside of sctp.

> So I'm thinking that we aim for 5.12-rc1 on all three patches with a cc:stable?

Thanks for looking after these!

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2021-02-07 23:48    [W:0.141 / U:3.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site