summaryrefslogtreecommitdiff
path: root/kernel/cred.c
diff options
context:
space:
mode:
authorXin Long <lucien.xin@gmail.com>2017-11-17 14:11:11 +0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-02-25 11:05:41 +0100
commit2e6712234606ce4b155723f71a3c9f52128d9266 (patch)
treeca3e86e6128bc2c0c552fcb75ba7227a3cee37f5 /kernel/cred.c
parent85552886b454b27588d4d7a01456ab5e82daaa47 (diff)
sctp: set frag_point in sctp_setsockopt_maxseg correctly
commit ecca8f88da5c4260cc2bccfefd2a24976704c366 upstream. Now in sctp_setsockopt_maxseg user_frag or frag_point can be set with val >= 8 and val <= SCTP_MAX_CHUNK_LEN. But both checks are incorrect. val >= 8 means frag_point can even be less than SCTP_DEFAULT_MINSEGMENT. Then in sctp_datamsg_from_user(), when it's value is greater than cookie echo len and trying to bundle with cookie echo chunk, the first_len will overflow. The worse case is when it's value is equal as cookie echo len, first_len becomes 0, it will go into a dead loop for fragment later on. In Hangbin syzkaller testing env, oom was even triggered due to consecutive memory allocation in that loop. Besides, SCTP_MAX_CHUNK_LEN is the max size of the whole chunk, it should deduct the data header for frag_point or user_frag check. This patch does a proper check with SCTP_DEFAULT_MINSEGMENT subtracting the sctphdr and datahdr, SCTP_MAX_CHUNK_LEN subtracting datahdr when setting frag_point via sockopt. It also improves sctp_setsockopt_maxseg codes. Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Reported-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'kernel/cred.c')
0 files changed, 0 insertions, 0 deletions