mlock.2: Note pre-4.9 bug in RLIMIT_MEMLOCK accounting for overlapping locks

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2016-12-16 13:34:47 +01:00
parent 7509f758ce
commit 4a8449e127
1 changed files with 23 additions and 0 deletions

View File

@ -445,6 +445,29 @@ that a privileged process can lock and the
soft resource limit instead defines a limit on how much memory an
unprivileged process may lock.
.SH BUGS
In Linux 4.8 and earlier,
a bug in the kernel's accounting of locked memory for unprivileged processes
(i.e., without
.BR CAP_IPC_LOCK )
meant that if the region specified by
.I addr
and
.I len
overlapped an existing lock,
then the already locked bytes in the overlapping region were counted twice
when checking against the limit.
Such double accounting could incorrectly calculate a "total locked memory"
value for the process that exceeded the
.BR RLIMIT_MEMLOCK
limit, with the result that
.BR mlock ()
and
.BR mlock2()
would fail on requests that should have succeeded.
This bug was fixed
.\" commit 0cf2f6f6dc605e587d2c1120f295934c77e810e8
in Linux 4.9
In the 2.4 series Linux kernels up to and including 2.4.17,
a bug caused the
.BR mlockall ()