[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <377697dd-15bc-4a2d-be19-1d136adb351c@redhat.com>
Date: Tue, 30 Sep 2025 16:31:02 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Deepak Sharma <deepak.sharma.472935@...il.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
horms@...nel.org, pwn9uin@...il.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kernel-mentees@...ts.linux.dev,
david.hunter.linux@...il.com, skhan@...uxfoundation.org,
syzbot+740e04c2a93467a0f8c8@...kaller.appspotmail.com,
syzbot+07b635b9c111c566af8b@...kaller.appspotmail.com
Subject: Re: [PATCH net v2] atm: Fix the cleanup on alloc_mpc failure in
atm_mpoa_mpoad_attach
On 9/30/25 3:33 PM, Deepak Sharma wrote:
> On Tue, Sep 30, 2025 at 2:15 PM Paolo Abeni <pabeni@...hat.com> wrote:
>> AFAICS the mpc_timer can rearm itself, so this the above is not enough
>> and you should use timer_shutdown_sync() instead.
>
> Hi,
>
> As I understand it, `timer_shutdown_sync` will prevent any further
> re-arming of the timer. I think this is not what we want here; since even if
> we somehow fail to allocate our first MPOA client object on our first
> ioctl call,
> and hence end up wanting to disarm the timer, maybe on next call we can
> allocate it successfully, and we would want that caches are processed
> (which are processed for every time out). So we still want it to be
> possible that
> we can re-arm it.
Ah, I missed the goal here is just being able to rearm the timer (i.e.
there is no related UaF).
Given the above, I think you could instead simply replace add_timer()
with mod_timer().
/P
Powered by blists - more mailing lists