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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aNai8qxJV9rL9wWf@horms.kernel.org>
Date: Fri, 26 Sep 2025 15:28:02 +0100
From: Simon Horman <horms@...nel.org>
To: Deepak Sharma <deepak.sharma.472935@...il.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, 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 Fri, Sep 26, 2025 at 02:12:51AM +0530, Deepak Sharma wrote:
> Syzbot reported a warning at `add_timer`, which is called from the
> `atm_mpoa_mpoad_attach` function
> 
> The reason for warning is that in the first call to the ioctl, if
> there is no MPOA client created yet (mpcs is the linked list for
> these MPOA clients) we do a `mpc_timer_refresh` to arm the timer.
> Later on, if the `alloc_mpc` fails (which on success will also
> initialize mpcs if it's first MPOA client created) and we didn't
> have any MPOA client yet, we return without the timer de-armed
> 
> If the same ioctl is called again, since we don't have any MPOA
> clients yet we again arm the timer, which might already be left
> armed by the previous call to this ioctl in which `alloc_mpc` failed
> 
> Hence, de-arm the timer in the event that `alloc_mpc` fails and we
> don't have any other MPOA client (that is, `mpcs` is NULL)
> 
> Do a `timer_delete_sync` instead of `timer_delete`, since the timer
> callback can arm it back again
> 
> This does not need to be done at the early return in case of
> `mpc->mpoad_vcc`, or a control channel to MPOAD already exists.
> The timer should remain there to periodically process caches
> 
> Reported-by: syzbot+07b635b9c111c566af8b@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=07b635b9c111c566af8b
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Deepak Sharma <deepak.sharma.472935@...il.com>
> ---
> v2:
>  - Improved commit message
>  - Fix the faulty condition check to disarm the timer
>  - Use `timer_delete_sync` instead to avoid re-arming of timer
> 
> v1:
>  - Disarm the timer using `timer_delete` in case `alloc_mpc`
>    fails`

Thanks for the update.

Reviewed-by: Simon Horman <horms@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ