Re: ipc/msg: zalloc struct msg_queue when creating a new msq
From: Manfred Spraul
Date: Wed Jul 04 2018 - 05:19:00 EST
This is a multi-part message in MIME format.
On 06/25/2018 11:21 AM, Dmitry Vyukov wrote:
On Sun, Jun 24, 2018 at 4:56 AM, Davidlohr Bueso <dave@xxxxxxxxxxxx> wrote:
There are 2 relevant values: kern_ipc_perm.id and kern_ipc_perm.seq.
The following splat was reported around the msg_queue structure
which can have uninitialized fields left over after newque().
Future syscalls which make use of the msq id (now valid) can thus
make KMSAN complain because not all fields are explicitly initialized
and we have the padding as well. This is internal to the kernel,
hence no bogus leaks.
As far as I understand the root problem is that (1) we publish a
not-fully initialized objects and (2) finish it's initialization in a
racy manner when other threads already have access to it. As the
result other threads can act on a wrong object. I am not sure that
zeroing the object really solves these problems. It will sure get rid
of the report at hand (but probably not of KTSAN, data race detector,
report), other threads still can see wrong 0 id and the id is still
initialized in racy way. I would expect that a proper fix would be to
publish a fully initialized object with proper, final id. Am I missing
For kern_ipc_perm.id, it is possible to move the access to the codepath
that hold the lock.
For kern_ipc_perm.seq, there are two options:
1) set it before publication.
2) initialize to an invalid value, and correct that at the end.
I'm in favor of option 2, it avoids that we must think about reducing
the next sequence number or not:
The purpose of the sequence counter is to minimize the risk that e.g. a
semop() will write into a newly created array.
I intentially write "minimize the risk", as it is by design impossible
to guarantee that this cannot happen, e.g. if semop() sleeps at the
instruction before the syscall.
Therefore, we can set seq to ULONG_MAX, then ipc_checkid() will always
fail and the corruption is avoided.
What do you think?
Just set seq to 0 is dangerous, as the first allocated sequence number
is 0, and if that object is destroyed, then the newly created object has
temporarily sequence number 0 as well.