From: Jeremy Cline <jeremy@jcline.org>
To: Edward Adam Davis <eadavis@qq.com>
Cc: habetsm.xilinx@gmail.com, davem@davemloft.net,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
reibax@gmail.com, richardcochran@gmail.com,
syzbot+df3f3ef31f60781fa911@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH net-next V2] ptp: fix corrupted list in ptp_open
Date: Thu, 2 Nov 2023 14:16:54 -0400 [thread overview]
Message-ID: <ZUPnlsm91R72MBs7@dev> (raw)
In-Reply-To: <tencent_2C67C6D2537B236F497823BCC457976F9705@qq.com>
Hi Edward,
On Tue, Oct 31, 2023 at 06:25:42PM +0800, Edward Adam Davis wrote:
> There is no lock protection when writing ptp->tsevqs in ptp_open(),
> ptp_release(), which can cause data corruption, use mutex lock to avoid this
> issue.
>
> Moreover, ptp_release() should not be used to release the queue in ptp_read(),
> and it should be deleted together.
>
> Reported-and-tested-by: syzbot+df3f3ef31f60781fa911@syzkaller.appspotmail.com
> Fixes: 8f5de6fb2453 ("ptp: support multiple timestamp event readers")
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> drivers/ptp/ptp_chardev.c | 11 +++++++++--
> drivers/ptp/ptp_clock.c | 3 +++
> drivers/ptp/ptp_private.h | 1 +
> 3 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
> index 282cd7d24077..e31551d2697d 100644
> --- a/drivers/ptp/ptp_chardev.c
> +++ b/drivers/ptp/ptp_chardev.c
> @@ -109,6 +109,9 @@ int ptp_open(struct posix_clock_context *pccontext, fmode_t fmode)
> struct timestamp_event_queue *queue;
> char debugfsname[32];
>
> + if (mutex_lock_interruptible(&ptp->tsevq_mux))
> + return -ERESTARTSYS;
> +
> queue = kzalloc(sizeof(*queue), GFP_KERNEL);
> if (!queue)
> return -EINVAL;
> @@ -132,15 +135,20 @@ int ptp_open(struct posix_clock_context *pccontext, fmode_t fmode)
> debugfs_create_u32_array("mask", 0444, queue->debugfs_instance,
> &queue->dfs_bitmap);
>
> + mutex_unlock(&ptp->tsevq_mux);
The lock doesn't need to be held so long here. Doing so causes a bit of
an issue, actually, because the memory allocation for the queue can fail
which will cause the function to return early without releasing the
mutex.
The lock only needs to be held for the list_add_tail() call.
> return 0;
> }
>
> int ptp_release(struct posix_clock_context *pccontext)
> {
> struct timestamp_event_queue *queue = pccontext->private_clkdata;
> + struct ptp_clock *ptp =
> + container_of(pccontext->clk, struct ptp_clock, clock);
> unsigned long flags;
>
> if (queue) {
> + if (mutex_lock_interruptible(&ptp->tsevq_mux))
> + return -ERESTARTSYS;
> debugfs_remove(queue->debugfs_instance);
> pccontext->private_clkdata = NULL;
> spin_lock_irqsave(&queue->lock, flags);
> @@ -148,6 +156,7 @@ int ptp_release(struct posix_clock_context *pccontext)
> spin_unlock_irqrestore(&queue->lock, flags);
> bitmap_free(queue->mask);
> kfree(queue);
> + mutex_unlock(&ptp->tsevq_mux);
Similar to the above note, you don't want to hold the lock any longer
than you must.
While this patch looks to cover adding and removing items from the list,
the code that iterates over the list isn't covered which can be
problematic. If the list is modified while it is being iterated, the
iterating code could chase an invalid pointer.
Regards,
Jeremy
next prev parent reply other threads:[~2023-11-02 18:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 10:25 [PATCH net-next V2] ptp: fix corrupted list in ptp_open Edward Adam Davis
2023-11-02 0:18 ` Richard Cochran
2023-11-02 18:16 ` Jeremy Cline [this message]
2023-11-02 23:12 ` Edward Adam Davis
2023-11-04 2:13 ` Richard Cochran
2023-11-04 2:15 ` Richard Cochran
-- strict thread matches above, loose matches on Subject: below --
2023-10-29 19:57 [PATCH-net-next] " Richard Cochran
2023-10-30 21:07 ` [PATCH net-next V2] " Edward Adam Davis
2023-10-31 9:28 ` Martin Habets
2023-11-02 0:12 ` Richard Cochran
2023-11-02 11:16 ` Edward Adam Davis
2023-11-03 23:15 ` Richard Cochran
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=ZUPnlsm91R72MBs7@dev \
--to=jeremy@jcline.org \
--cc=davem@davemloft.net \
--cc=eadavis@qq.com \
--cc=habetsm.xilinx@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=reibax@gmail.com \
--cc=richardcochran@gmail.com \
--cc=syzbot+df3f3ef31f60781fa911@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).