From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7670034DB4D for ; Thu, 29 Jan 2026 22:30:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769725858; cv=none; b=jPHIT1NQS/Cf0MYsDBCh3atXhXxt2JFMLYIeMQtFjv/nZIHuQ6Ysm8WqNUWnMrIvzEJWGdFuN/DPJp058Bg5dBfq8AXU3iEMU5njK0RosbxX1FI3ZtjKbav9wCRulFG/j00Oz0wqvO+9Em7Mq0h5dxCLGHwwJr9T0e/50vH1rs8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769725858; c=relaxed/simple; bh=fvSTzBiE8NLPO9EJ2v3UadUTQjAub1kStG5sbI5j4FM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DMy3sZoy0O6oEal/IRt4LAbR7wDxm65ca64iHJj200a9g/Hge8y1Ub0/pE+qoo3+vfiu1v5+msEasnagrXwclIGcdDDKitYehRI2ZPTgrwQAq2qlO57u1uTUtQEHriOGTHp+5ksIr+la2JYVf+6n7hAUyEIaaJo2FppZdgZuEZM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=f+TL5o0a; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=b4/+eD8Q; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="f+TL5o0a"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="b4/+eD8Q" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769725855; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HISVrISF5RMSZoDqWrQf2bDEMP3jBXDbMHTqhsJe8fY=; b=f+TL5o0a46mgc4ylCflgFG61OSDF4hOf+HLOseND7//G+e1ITZj4I/qBzgTGLI0i+XPgXD //9CgMrLsALG2EbE/nTisxltWl/d2Cqf2WXm1jVTwUlFbiVo+KmNWMGgok5DM4XzCHUU0b /StqVun7Y+0wufJpTd1u50Cm9Lu1IC4= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-207-TjuevNdjOMmvShBz2VHxxQ-1; Thu, 29 Jan 2026 17:30:54 -0500 X-MC-Unique: TjuevNdjOMmvShBz2VHxxQ-1 X-Mimecast-MFC-AGG-ID: TjuevNdjOMmvShBz2VHxxQ_1769725853 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-47ee1fe7b24so12488015e9.1 for ; Thu, 29 Jan 2026 14:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769725853; x=1770330653; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=HISVrISF5RMSZoDqWrQf2bDEMP3jBXDbMHTqhsJe8fY=; b=b4/+eD8QppESym2gF99/xM5hPogZ2C+l6tFdieHUVvf+B+8E1aqrfmdY0p8WG/jfGG I45ZGcbwPm2NexgQy4WpDxApmiLt59T+FYafVGJtw441nb2Q2AXVGwhYIRAWHa7VTH2f dSLbpROrqUY61Mib9kYrdRiVijeRnsFlOgr4U84f5vQMXnOhk7UeuBky1ffcZLi8Kalm ba6WNDo2G9ls12c0lt6gTIEz9swR3dIXjEGCW6jrMBycS+8ehl0Z35ahqqeKiIV+5euO FEya9J02WLfW5uVcEUdhZ5r2ODTOXMjfDAaVe5kql05w+0k4909/AFfQVpLbGJBtIaFJ +uhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769725853; x=1770330653; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HISVrISF5RMSZoDqWrQf2bDEMP3jBXDbMHTqhsJe8fY=; b=tAqu0Jd4SrWMXFVE3GR/SPh8XnqGwugngxolp0IqaQSz9O3kCSehRm+mPEI9A+t8gs PHE0RaIgf6nn3OCpKkcKevRnXvBlR6AUxL4zj5Axs4vojBllzNKzpkJOapyzUEwQSriX LAYNdVz5NDbTCqclr5m6Vi46f1bxQvfHBAs+SVP/Xqfmr1oGFfbOKdF7p41fvw71rYwP fAh8nwgb1pHQGPBXc96QSTxV5tc8dOL4QW825CxbATWLjrHuEgrajj5iaKqaE1k9Qbhe +TqJr4iAeDJwqubiK7khYbqs6NY9FWnCJn4/MeqvH0ICjJTQLrei8rtw8zwpNC7Z0vpA IJPQ== X-Forwarded-Encrypted: i=1; AJvYcCVX3h26H4ClhJziE9qexvRaUD4+fzlWJRY70+LXJG3DDXc2/Qv73E2KwGGlilMm43JnYjfbbOjUTraN2+M=@vger.kernel.org X-Gm-Message-State: AOJu0YxC0n5YwFwm1HkGqEXkfJdFeEMxFGgIBSdo5VWsDT0JGVEzufdm Ol9gh5AZ+qLaYYJRvqAEheukvxes9k2SEk35uMVVRh4aF/MiQC7gjk6e7vV1ZlDCd+fElSULYpS TUDVHfVojO5/g9RHHnWCNST5hUtx8DwFBsrm7cm/Caj0W1rzzWaREgttfKurz3EHaKQ== X-Gm-Gg: AZuq6aKIUidper3ez5kJpjQG3rF8/r+1cl5tBzySj+3k7+7qJQS199mLsSg9CAodVBF qHd35Z35rGTjd8Ajo866gJ1n9L5FHwAL7JfWn0XjGYaRh84Q0eGIyaFOIID6QZKFbjlfKLGrGN8 UEcZ8KHw8InsiKStToxhXGRBJM1YJKvBLs2laccY5rZwtzS7yMYSn7AIyPUjAxhgxstSd0sO47t p9Kc7zGubIbtOE/mqigi8Hclay9K8/w2zVmUu7nlNspVr/vqPGwiYzwqAECmq01SMWm1bfuNSUW kc7a2xB9yn853cpnZviwCsAu5U7+5Z7vgJMvoHh5Lg0STQKupYgVpsJ1CfQhyLks2EIa7dxda/j Sfa2wj2cw X-Received: by 2002:a05:600c:8b42:b0:477:5af7:6fa with SMTP id 5b1f17b1804b1-482db49728bmr6339885e9.32.1769725852806; Thu, 29 Jan 2026 14:30:52 -0800 (PST) X-Received: by 2002:a05:600c:8b42:b0:477:5af7:6fa with SMTP id 5b1f17b1804b1-482db49728bmr6339665e9.32.1769725852329; Thu, 29 Jan 2026 14:30:52 -0800 (PST) Received: from [192.168.2.83] ([46.175.183.46]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4806cddffc0sm196670045e9.5.2026.01.29.14.30.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 14:30:51 -0800 (PST) Message-ID: <5db7d6b4-5aa4-409d-a21b-51ed8c56ccb7@redhat.com> Date: Thu, 29 Jan 2026 23:30:48 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Intel-wired-lan] [PATCH net] iavf: fix PTP use-after-free during reset To: Paul Menzel Cc: netdev@vger.kernel.org, ivecera@redhat.com, Przemek Kitszel , Richard Cochran , Eric Dumazet , linux-kernel@vger.kernel.org, Andrew Lunn , Tony Nguyen , Simon Horman , Mateusz Polchlopek , Jacob Keller , Jakub Kicinski , Paolo Abeni , "David S. Miller" , intel-wired-lan@lists.osuosl.org References: <20260129095723.7269-1-poros@redhat.com> Content-Language: en-US From: Petr Oros In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/29/26 22:48, Paul Menzel wrote: > Dear Petr, > > > Thank you for the patch. > > Am 29.01.26 um 10:57 schrieb Petr Oros: >> Commit 7c01dbfc8a1c5f ("iavf: periodically cache PHC time") introduced a >> worker to cache PHC time, but failed to stop it during reset or disable. >> >> This creates a race condition where `iavf_reset_task()` or >> `iavf_disable_vf()` free adapter resources (AQ) while the worker is >> still >> running. If the worker triggers `iavf_queue_ptp_cmd()` during >> teardown, it >> accesses freed memory/locks, leading to a crash. > > Do you have a stacktrace, and could you add an excerpt, so people > hitting this, can more easily find the commit? I have some stack traces. The problem is that the race window is so wide that it sometimes crashes in the PTP subsystem, looking like: [ 5611.939379] Call Trace: [ 5611.941831]  [ 5611.943937]  ? show_trace_log_lvl+0x1b0/0x2f0 [ 5611.948295]  ? show_trace_log_lvl+0x1b0/0x2f0 [ 5611.952656]  ? ptp_aux_kworker+0x1d/0x40 [ 5611.956584]  ? __die_body.cold+0x8/0x12 [ 5611.960422]  ? page_fault_oops+0x148/0x160 [ 5611.964520]  ? exc_page_fault+0x73/0x160 [ 5611.968445]  ? asm_exc_page_fault+0x26/0x30 [ 5611.972634]  ? __pfx_ptp_aux_kworker+0x10/0x10 [ 5611.977082]  ? __pfx_ptp_aux_kworker+0x10/0x10 [ 5611.981525]  ptp_aux_kworker+0x1d/0x40 [ 5611.985278]  kthread_worker_fn+0xa0/0x260 [ 5611.989291]  ? __pfx_kthread_worker_fn+0x10/0x10 [ 5611.993911]  kthread+0xfd/0x240 [ 5611.997056]  ? __pfx_kthread+0x10/0x10 [ 5612.000809]  ret_from_fork+0x34/0x50 [ 5612.004386]  ? __pfx_kthread+0x10/0x10 [ 5612.008140]  ret_from_fork_asm+0x1a/0x30 [ 5612.012069]   and other times in iavf, looking like: 3476.640150] Call Trace: [ 3476.642597]  [ 3476.644702]  ? show_trace_log_lvl+0x1b0/0x2f0 [ 3476.649062]  ? show_trace_log_lvl+0x1b0/0x2f0 [ 3476.653420]  ? mod_delayed_work_on+0x9f/0xb0 [ 3476.657691]  ? __die_body.cold+0x8/0x12 [ 3476.661530]  ? page_fault_oops+0x148/0x160 [ 3476.665629]  ? exc_page_fault+0x7f/0x150 [ 3476.669556]  ? asm_exc_page_fault+0x26/0x30 [ 3476.673743]  ? __queue_work.part.0+0x44/0x320 [ 3476.678100]  ? __pfx_ptp_aux_kworker+0x10/0x10 [ 3476.682547]  mod_delayed_work_on+0x9f/0xb0 [ 3476.686647]  iavf_send_phc_read+0xb0/0xd0 [iavf] [ 3476.691283]  iavf_ptp_do_aux_work+0x39/0x50 [iavf] [ 3476.696083]  ptp_aux_kworker+0x1d/0x40 [ 3476.699835]  kthread_worker_fn+0xa3/0x260 [ 3476.703848]  ? __pfx_kthread_worker_fn+0x10/0x10 [ 3476.708465]  kthread+0xfa/0x240 [ 3476.711613]  ? __pfx_kthread+0x10/0x10 [ 3476.715365]  ret_from_fork+0x34/0x50 [ 3476.718943]  ? __pfx_kthread+0x10/0x10 [ 3476.722695]  ret_from_fork_asm+0x1a/0x30 [ 3476.726622]  , etc. > >> Fix this by calling `iavf_ptp_release()` before tearing down the >> adapter. >> This ensures `ptp_clock_unregister()` synchronously cancels the >> worker and >> cleans up the chardev before the backing resources are destroyed. >> >> Fixes: 7c01dbfc8a1c5f ("iavf: periodically cache PHC time") >> Signed-off-by: Petr Oros >> --- >>   drivers/net/ethernet/intel/iavf/iavf_main.c | 4 ++++ >>   1 file changed, 4 insertions(+) >> >> diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c >> b/drivers/net/ethernet/intel/iavf/iavf_main.c >> index 4b0fc8f354bc90..0dd58ce5a53ab1 100644 >> --- a/drivers/net/ethernet/intel/iavf/iavf_main.c >> +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c >> @@ -3025,6 +3025,8 @@ static void iavf_disable_vf(struct iavf_adapter >> *adapter) >>         adapter->flags |= IAVF_FLAG_PF_COMMS_FAILED; >>   +    iavf_ptp_release(adapter); >> + >>       /* We don't use netif_running() because it may be true prior to >>        * ndo_open() returning, so we can't assume it means all our open >>        * tasks have finished, since we're not holding the rtnl_lock >> here. >> @@ -3200,6 +3202,8 @@ static void iavf_reset_task(struct work_struct >> *work) >>       iavf_change_state(adapter, __IAVF_RESETTING); >>       adapter->flags &= ~IAVF_FLAG_RESET_PENDING; >>   +    iavf_ptp_release(adapter); >> + >>       /* free the Tx/Rx rings and descriptors, might be better to just >>        * re-use them sometime in the future >>        */ > > Reviewed-by: Paul Menzel > > > Kind regards, > > Paul >