lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 01 May 2019 09:19:48 -0400 (EDT) From: David Miller <davem@...emloft.net> To: lucien.xin@...il.com Cc: netdev@...r.kernel.org, linux-sctp@...r.kernel.org, marcelo.leitner@...il.com, nhorman@...driver.com Subject: Re: [PATCH net] sctp: avoid running the sctp state machine recursively From: Xin Long <lucien.xin@...il.com> Date: Mon, 29 Apr 2019 14:16:19 +0800 > Ying triggered a call trace when doing an asconf testing: ... > As it shows, the first sctp_do_sm() running under atomic context (NET_RX > softirq) invoked sctp_primitive_ASCONF() that uses GFP_KERNEL flag later, > and this flag is supposed to be used in non-atomic context only. Besides, > sctp_do_sm() was called recursively, which is not expected. > > Vlad tried to fix this recursive call in Commit c0786693404c ("sctp: Fix > oops when sending queued ASCONF chunks") by introducing a new command > SCTP_CMD_SEND_NEXT_ASCONF. But it didn't work as this command is still > used in the first sctp_do_sm() call, and sctp_primitive_ASCONF() will > be called in this command again. > > To avoid calling sctp_do_sm() recursively, we send the next queued ASCONF > not by sctp_primitive_ASCONF(), but by sctp_sf_do_prm_asconf() in the 1st > sctp_do_sm() directly. > > Reported-by: Ying Xu <yinxu@...hat.com> > Signed-off-by: Xin Long <lucien.xin@...il.com> Applied and queued up for -stable.
Powered by blists - more mailing lists