From: Lee Jones <lee.jones@linaro.org>
To: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Vlad Yasevich <vyasevich@gmail.com>,
Neil Horman <nhorman@tuxdriver.com>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
lksctp developers <linux-sctp@vger.kernel.org>,
"H.P. Yarroll" <piggy@acm.org>,
Karl Knutson <karl@athena.chicago.il.us>,
Jon Grimm <jgrimm@us.ibm.com>,
Xingang Guo <xingang.guo@intel.com>,
Hui Huang <hui.huang@nokia.com>,
Sridhar Samudrala <sri@us.ibm.com>,
Daisy Chang <daisyc@us.ibm.com>, Ryan Layer <rmlayer@us.ibm.com>,
Kevin Gao <kevin.gao@intel.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH 2/2] sctp: hold cached endpoints to prevent possible UAF
Date: Wed, 15 Dec 2021 06:49:30 +0000 [thread overview]
Message-ID: <YbmP+gzoCyKiEJBM@google.com> (raw)
In-Reply-To: <20211214192301.1496754-1-lee.jones@linaro.org>
On Tue, 14 Dec 2021, Lee Jones wrote:
> The cause of the resultant dump_stack() reported below is a
> dereference of a freed pointer to 'struct sctp_endpoint' in
> sctp_sock_dump().
>
> This race condition occurs when a transport is cached into its
> associated hash table followed by an endpoint/sock migration to a new
> association in sctp_assoc_migrate() prior to their subsequent use in
> sctp_diag_dump() which uses sctp_for_each_transport() to walk the hash
> table calling into sctp_sock_dump() where the dereference occurs.
>
> BUG: KASAN: use-after-free in sctp_sock_dump+0xa8/0x438 [sctp_diag]
> Call trace:
> dump_backtrace+0x0/0x2dc
> show_stack+0x20/0x2c
> dump_stack+0x120/0x144
> print_address_description+0x80/0x2f4
> __kasan_report+0x174/0x194
> kasan_report+0x10/0x18
> __asan_load8+0x84/0x8c
> sctp_sock_dump+0xa8/0x438 [sctp_diag]
> sctp_for_each_transport+0x1e0/0x26c [sctp]
> sctp_diag_dump+0x180/0x1f0 [sctp_diag]
> inet_diag_dump+0x12c/0x168
> netlink_dump+0x24c/0x5b8
> __netlink_dump_start+0x274/0x2a8
> inet_diag_handler_cmd+0x224/0x274
> sock_diag_rcv_msg+0x21c/0x230
> netlink_rcv_skb+0xe0/0x1bc
> sock_diag_rcv+0x34/0x48
> netlink_unicast+0x3b4/0x430
> netlink_sendmsg+0x4f0/0x574
> sock_write_iter+0x18c/0x1f0
> do_iter_readv_writev+0x230/0x2a8
> do_iter_write+0xc8/0x2b4
> vfs_writev+0xf8/0x184
> do_writev+0xb0/0x1a8
> __arm64_sys_writev+0x4c/0x5c
> el0_svc_common+0x118/0x250
> el0_svc_handler+0x3c/0x9c
> el0_svc+0x8/0xc
>
> To prevent this from happening we need to take a references to the
> to-be-used/dereferenced 'struct sock' and 'struct sctp_endpoint's
> until such a time when we know it can be safely released.
>
> When KASAN is not enabled, a similar, but slightly different NULL
> pointer derefernce crash occurs later along the thread of execution in
> inet_sctp_diag_fill() this time.
>
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: lksctp developers <linux-sctp@vger.kernel.org>
> Cc: "H.P. Yarroll" <piggy@acm.org>
> Cc: Karl Knutson <karl@athena.chicago.il.us>
> Cc: Jon Grimm <jgrimm@us.ibm.com>
> Cc: Xingang Guo <xingang.guo@intel.com>
> Cc: Hui Huang <hui.huang@nokia.com>
> Cc: Sridhar Samudrala <sri@us.ibm.com>
> Cc: Daisy Chang <daisyc@us.ibm.com>
> Cc: Ryan Layer <rmlayer@us.ibm.com>
> Cc: Kevin Gao <kevin.gao@intel.com>
> Cc: linux-sctp@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> net/sctp/diag.c | 4 ++++
> 1 file changed, 4 insertions(+)
Ignore this one. For some reason 1/2 didn't send.
Submitted a RESEND of the set.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Vlad Yasevich <vyasevich@gmail.com>,
Neil Horman <nhorman@tuxdriver.com>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
lksctp developers <linux-sctp@vger.kernel.org>,
"H.P. Yarroll" <piggy@acm.org>,
Karl Knutson <karl@athena.chicago.il.us>,
Jon Grimm <jgrimm@us.ibm.com>,
Xingang Guo <xingang.guo@intel.com>,
Hui Huang <hui.huang@nokia.com>,
Sridhar Samudrala <sri@us.ibm.com>,
Daisy Chang <daisyc@us.ibm.com>, Ryan Layer <rmlayer@us.ibm.com>,
Kevin Gao <kevin.gao@intel.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH 2/2] sctp: hold cached endpoints to prevent possible UAF
Date: Wed, 15 Dec 2021 06:49:30 +0000 [thread overview]
Message-ID: <YbmP+gzoCyKiEJBM@google.com> (raw)
In-Reply-To: <20211214192301.1496754-1-lee.jones@linaro.org>
On Tue, 14 Dec 2021, Lee Jones wrote:
> The cause of the resultant dump_stack() reported below is a
> dereference of a freed pointer to 'struct sctp_endpoint' in
> sctp_sock_dump().
>
> This race condition occurs when a transport is cached into its
> associated hash table followed by an endpoint/sock migration to a new
> association in sctp_assoc_migrate() prior to their subsequent use in
> sctp_diag_dump() which uses sctp_for_each_transport() to walk the hash
> table calling into sctp_sock_dump() where the dereference occurs.
>
> BUG: KASAN: use-after-free in sctp_sock_dump+0xa8/0x438 [sctp_diag]
> Call trace:
> dump_backtrace+0x0/0x2dc
> show_stack+0x20/0x2c
> dump_stack+0x120/0x144
> print_address_description+0x80/0x2f4
> __kasan_report+0x174/0x194
> kasan_report+0x10/0x18
> __asan_load8+0x84/0x8c
> sctp_sock_dump+0xa8/0x438 [sctp_diag]
> sctp_for_each_transport+0x1e0/0x26c [sctp]
> sctp_diag_dump+0x180/0x1f0 [sctp_diag]
> inet_diag_dump+0x12c/0x168
> netlink_dump+0x24c/0x5b8
> __netlink_dump_start+0x274/0x2a8
> inet_diag_handler_cmd+0x224/0x274
> sock_diag_rcv_msg+0x21c/0x230
> netlink_rcv_skb+0xe0/0x1bc
> sock_diag_rcv+0x34/0x48
> netlink_unicast+0x3b4/0x430
> netlink_sendmsg+0x4f0/0x574
> sock_write_iter+0x18c/0x1f0
> do_iter_readv_writev+0x230/0x2a8
> do_iter_write+0xc8/0x2b4
> vfs_writev+0xf8/0x184
> do_writev+0xb0/0x1a8
> __arm64_sys_writev+0x4c/0x5c
> el0_svc_common+0x118/0x250
> el0_svc_handler+0x3c/0x9c
> el0_svc+0x8/0xc
>
> To prevent this from happening we need to take a references to the
> to-be-used/dereferenced 'struct sock' and 'struct sctp_endpoint's
> until such a time when we know it can be safely released.
>
> When KASAN is not enabled, a similar, but slightly different NULL
> pointer derefernce crash occurs later along the thread of execution in
> inet_sctp_diag_fill() this time.
>
> Cc: Vlad Yasevich <vyasevich@gmail.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: lksctp developers <linux-sctp@vger.kernel.org>
> Cc: "H.P. Yarroll" <piggy@acm.org>
> Cc: Karl Knutson <karl@athena.chicago.il.us>
> Cc: Jon Grimm <jgrimm@us.ibm.com>
> Cc: Xingang Guo <xingang.guo@intel.com>
> Cc: Hui Huang <hui.huang@nokia.com>
> Cc: Sridhar Samudrala <sri@us.ibm.com>
> Cc: Daisy Chang <daisyc@us.ibm.com>
> Cc: Ryan Layer <rmlayer@us.ibm.com>
> Cc: Kevin Gao <kevin.gao@intel.com>
> Cc: linux-sctp@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> net/sctp/diag.c | 4 ++++
> 1 file changed, 4 insertions(+)
Ignore this one. For some reason 1/2 didn't send.
Submitted a RESEND of the set.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-12-15 6:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-14 19:23 [PATCH 2/2] sctp: hold cached endpoints to prevent possible UAF Lee Jones
2021-12-14 19:23 ` Lee Jones
2021-12-15 6:49 ` Lee Jones [this message]
2021-12-15 6:49 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YbmP+gzoCyKiEJBM@google.com \
--to=lee.jones@linaro.org \
--cc=daisyc@us.ibm.com \
--cc=davem@davemloft.net \
--cc=hui.huang@nokia.com \
--cc=jgrimm@us.ibm.com \
--cc=karl@athena.chicago.il.us \
--cc=kevin.gao@intel.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=piggy@acm.org \
--cc=rmlayer@us.ibm.com \
--cc=sri@us.ibm.com \
--cc=vyasevich@gmail.com \
--cc=xingang.guo@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.