]> git.proxmox.com Git - mirror_ubuntu-bionic-kernel.git/commit
sunrpc: expiry_time should be seconds not timeval
authorRoberto Bergantinos Corpas <rbergant@redhat.com>
Tue, 4 Feb 2020 10:32:56 +0000 (11:32 +0100)
committerKhalid Elmously <khalid.elmously@canonical.com>
Fri, 13 Mar 2020 04:31:00 +0000 (00:31 -0400)
commit04dbaef156330d8b84df86b58dbe6c8947f0f52c
tree94626586a9540ad15a28c2ee840a82a383db1d9b
parent7cd7462247c4fc97fceafb443eb6dbbc0d57c997
sunrpc: expiry_time should be seconds not timeval

BugLink: https://bugs.launchpad.net/bugs/1866678
commit 3d96208c30f84d6edf9ab4fac813306ac0d20c10 upstream.

When upcalling gssproxy, cache_head.expiry_time is set as a
timeval, not seconds since boot. As such, RPC cache expiry
logic will not clean expired objects created under
auth.rpcsec.context cache.

This has proven to cause kernel memory leaks on field. Using
64 bit variants of getboottime/timespec

Expiration times have worked this way since 2010's c5b29f885afe "sunrpc:
use seconds since boot in expiry cache".  The gssproxy code introduced
in 2012 added gss_proxy_save_rsc and introduced the bug.  That's a while
for this to lurk, but it required a bit of an extreme case to make it
obvious.

Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 030d794bf498 "SUNRPC: Use gssproxy upcall for server..."
Tested-By: Frank Sorenson <sorenson@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
net/sunrpc/auth_gss/svcauth_gss.c