diff options
author | Xin Long <lucien.xin@gmail.com> | 2019-03-20 14:49:38 +0800 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-04-03 06:27:25 +0200 |
commit | 118ad2c7de1d1d91bebec1430b4c47e3f5ebaa99 (patch) | |
tree | 8374f20f00bfd6077efa9d3515b55da443e1a532 /net/ipv6/tcp_ipv6.c | |
parent | d2af0ce54b1cbc82813b388b759877a2c6e53265 (diff) | |
download | talos-obmc-linux-118ad2c7de1d1d91bebec1430b4c47e3f5ebaa99.tar.gz talos-obmc-linux-118ad2c7de1d1d91bebec1430b4c47e3f5ebaa99.zip |
sctp: use memdup_user instead of vmemdup_user
[ Upstream commit ef82bcfa671b9a635bab5fa669005663d8b177c5 ]
In sctp_setsockopt_bindx()/__sctp_setsockopt_connectx(), it allocates
memory with addrs_size which is passed from userspace. We used flag
GFP_USER to put some more restrictions on it in Commit cacc06215271
("sctp: use GFP_USER for user-controlled kmalloc").
However, since Commit c981f254cc82 ("sctp: use vmemdup_user() rather
than badly open-coding memdup_user()"), vmemdup_user() has been used,
which doesn't check GFP_USER flag when goes to vmalloc_*(). So when
addrs_size is a huge value, it could exhaust memory and even trigger
oom killer.
This patch is to use memdup_user() instead, in which GFP_USER would
work to limit the memory allocation with a huge addrs_size.
Note we can't fix it by limiting 'addrs_size', as there's no demand
for it from RFC.
Reported-by: syzbot+ec1b7575afef85a0e5ca@syzkaller.appspotmail.com
Fixes: c981f254cc82 ("sctp: use vmemdup_user() rather than badly open-coding memdup_user()")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'net/ipv6/tcp_ipv6.c')
0 files changed, 0 insertions, 0 deletions