* [PATCH net] mptcp: Ensure RCU read lock is held when calling mptcp_sched_find()
@ 2024-10-30 14:02 Breno Leitao
2024-10-30 14:18 ` Eric Dumazet
2024-10-30 14:45 ` Matthieu Baerts
0 siblings, 2 replies; 6+ messages in thread
From: Breno Leitao @ 2024-10-30 14:02 UTC (permalink / raw)
To: kuba, horms, davem, edumazet, pabeni, Matthieu Baerts,
Mat Martineau, Geliang Tang
Cc: netdev, linux-kernel, vlad.wing, max, kernel-team, aehkn, stable,
open list:NETWORKING [MPTCP]
The mptcp_sched_find() function must be called with the RCU read lock
held, as it accesses RCU-protected data structures. This requirement was
not properly enforced in the mptcp_init_sock() function, leading to a
RCU list traversal in a non-reader section error when
CONFIG_PROVE_RCU_LIST is enabled.
net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!
Fix it by acquiring the RCU read lock before calling the
mptcp_sched_find() function. This ensures that the function is invoked
with the necessary RCU protection in place, as it accesses RCU-protected
data structures.
Additionally, the patch breaks down the mptcp_init_sched() call into
smaller parts, with the RCU read lock only covering the specific call to
mptcp_sched_find(). This helps minimize the critical section, reducing
the time during which RCU grace periods are blocked.
The mptcp_sched_list_lock is not held in this case, and it is not clear
if it is necessary.
Signed-off-by: Breno Leitao <leitao@debian.org>
Fixes: 1730b2b2c5a5 ("mptcp: add sched in mptcp_sock")
Cc: stable@vger.kernel.org
---
net/mptcp/protocol.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 6d0e201c3eb2..8ece630f80d4 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -2854,6 +2854,7 @@ static void mptcp_ca_reset(struct sock *sk)
static int mptcp_init_sock(struct sock *sk)
{
struct net *net = sock_net(sk);
+ struct mptcp_sched_ops *sched;
int ret;
__mptcp_init_sock(sk);
@@ -2864,8 +2865,10 @@ static int mptcp_init_sock(struct sock *sk)
if (unlikely(!net->mib.mptcp_statistics) && !mptcp_mib_alloc(net))
return -ENOMEM;
- ret = mptcp_init_sched(mptcp_sk(sk),
- mptcp_sched_find(mptcp_get_scheduler(net)));
+ rcu_read_lock();
+ sched = mptcp_sched_find(mptcp_get_scheduler(net));
+ rcu_read_unlock();
+ ret = mptcp_init_sched(mptcp_sk(sk), sched);
if (ret)
return ret;
--
2.43.5
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net] mptcp: Ensure RCU read lock is held when calling mptcp_sched_find()
2024-10-30 14:02 [PATCH net] mptcp: Ensure RCU read lock is held when calling mptcp_sched_find() Breno Leitao
@ 2024-10-30 14:18 ` Eric Dumazet
2024-10-30 15:05 ` Breno Leitao
2024-10-30 14:45 ` Matthieu Baerts
1 sibling, 1 reply; 6+ messages in thread
From: Eric Dumazet @ 2024-10-30 14:18 UTC (permalink / raw)
To: Breno Leitao
Cc: kuba, horms, davem, pabeni, Matthieu Baerts, Mat Martineau,
Geliang Tang, netdev, linux-kernel, vlad.wing, max, kernel-team,
aehkn, stable, open list:NETWORKING [MPTCP]
On Wed, Oct 30, 2024 at 3:02 PM Breno Leitao <leitao@debian.org> wrote:
>
> The mptcp_sched_find() function must be called with the RCU read lock
> held, as it accesses RCU-protected data structures. This requirement was
> not properly enforced in the mptcp_init_sock() function, leading to a
> RCU list traversal in a non-reader section error when
> CONFIG_PROVE_RCU_LIST is enabled.
>
> net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!
>
> Fix it by acquiring the RCU read lock before calling the
> mptcp_sched_find() function. This ensures that the function is invoked
> with the necessary RCU protection in place, as it accesses RCU-protected
> data structures.
>
> Additionally, the patch breaks down the mptcp_init_sched() call into
> smaller parts, with the RCU read lock only covering the specific call to
> mptcp_sched_find(). This helps minimize the critical section, reducing
> the time during which RCU grace periods are blocked.
>
> The mptcp_sched_list_lock is not held in this case, and it is not clear
> if it is necessary.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> Fixes: 1730b2b2c5a5 ("mptcp: add sched in mptcp_sock")
> Cc: stable@vger.kernel.org
> ---
> net/mptcp/protocol.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 6d0e201c3eb2..8ece630f80d4 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -2854,6 +2854,7 @@ static void mptcp_ca_reset(struct sock *sk)
> static int mptcp_init_sock(struct sock *sk)
> {
> struct net *net = sock_net(sk);
> + struct mptcp_sched_ops *sched;
> int ret;
>
> __mptcp_init_sock(sk);
> @@ -2864,8 +2865,10 @@ static int mptcp_init_sock(struct sock *sk)
> if (unlikely(!net->mib.mptcp_statistics) && !mptcp_mib_alloc(net))
> return -ENOMEM;
>
> - ret = mptcp_init_sched(mptcp_sk(sk),
> - mptcp_sched_find(mptcp_get_scheduler(net)));
> + rcu_read_lock();
> + sched = mptcp_sched_find(mptcp_get_scheduler(net));
> + rcu_read_unlock();
You are silencing the warning, but a potential UAF remains.
sched could have been freed already, it is illegal to deref it.
> + ret = mptcp_init_sched(mptcp_sk(sk), sched);
The rcu_read_unlock() should be moved after this point.
This means that mptcp_sched_ops ->init() functions are not allowed to sleep.
> if (ret)
> return ret;
>
> --
> 2.43.5
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net] mptcp: Ensure RCU read lock is held when calling mptcp_sched_find()
2024-10-30 14:02 [PATCH net] mptcp: Ensure RCU read lock is held when calling mptcp_sched_find() Breno Leitao
2024-10-30 14:18 ` Eric Dumazet
@ 2024-10-30 14:45 ` Matthieu Baerts
2024-10-30 15:01 ` Breno Leitao
1 sibling, 1 reply; 6+ messages in thread
From: Matthieu Baerts @ 2024-10-30 14:45 UTC (permalink / raw)
To: Breno Leitao
Cc: kuba, horms, davem, edumazet, pabeni, Mat Martineau,
Geliang Tang, netdev, linux-kernel, vlad.wing, max, kernel-team,
aehkn, stable, open list:NETWORKING [MPTCP]
Hi Breno
30 Oct 2024 15:02:45 Breno Leitao <leitao@debian.org>:
> The mptcp_sched_find() function must be called with the RCU read lock
> held, as it accesses RCU-protected data structures. This requirement was
> not properly enforced in the mptcp_init_sock() function, leading to a
> RCU list traversal in a non-reader section error when
> CONFIG_PROVE_RCU_LIST is enabled.
>
> net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!
>
> Fix it by acquiring the RCU read lock before calling the
> mptcp_sched_find() function. This ensures that the function is invoked
> with the necessary RCU protection in place, as it accesses RCU-protected
> data structures.
Thank you for having looked at that, but there is already a fix:
https://lore.kernel.org/netdev/20241021-net-mptcp-sched-lock-v1-1-637759cf061c@kernel.org/
This fix has even been applied in the net tree already:
https://git.kernel.org/netdev/net/c/3deb12c788c3
Did you not get conflicts when rebasing your branch on top of the
latest version?
> Additionally, the patch breaks down the mptcp_init_sched() call into
> smaller parts, with the RCU read lock only covering the specific call to
> mptcp_sched_find(). This helps minimize the critical section, reducing
> the time during which RCU grace periods are blocked.
I agree with Eric (thank you for the review!): this creates other issues.
> The mptcp_sched_list_lock is not held in this case, and it is not clear
> if it is necessary.
It is not needed, the list is not modified, only read with RCU.
Cheers,
Matt
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net] mptcp: Ensure RCU read lock is held when calling mptcp_sched_find()
2024-10-30 14:45 ` Matthieu Baerts
@ 2024-10-30 15:01 ` Breno Leitao
0 siblings, 0 replies; 6+ messages in thread
From: Breno Leitao @ 2024-10-30 15:01 UTC (permalink / raw)
To: Matthieu Baerts
Cc: kuba, horms, davem, edumazet, pabeni, Mat Martineau,
Geliang Tang, netdev, linux-kernel, vlad.wing, max, kernel-team,
aehkn, stable, open list:NETWORKING [MPTCP]
Hello Matthieu,
On Wed, Oct 30, 2024 at 03:45:02PM +0100, Matthieu Baerts wrote:
> Hi Breno
>
> 30 Oct 2024 15:02:45 Breno Leitao <leitao@debian.org>:
>
> > The mptcp_sched_find() function must be called with the RCU read lock
> > held, as it accesses RCU-protected data structures. This requirement was
> > not properly enforced in the mptcp_init_sock() function, leading to a
> > RCU list traversal in a non-reader section error when
> > CONFIG_PROVE_RCU_LIST is enabled.
> >
> > net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!
> >
> > Fix it by acquiring the RCU read lock before calling the
> > mptcp_sched_find() function. This ensures that the function is invoked
> > with the necessary RCU protection in place, as it accesses RCU-protected
> > data structures.
>
> Thank you for having looked at that, but there is already a fix:
>
> https://lore.kernel.org/netdev/20241021-net-mptcp-sched-lock-v1-1-637759cf061c@kernel.org/
>
> This fix has even been applied in the net tree already:
>
> https://git.kernel.org/netdev/net/c/3deb12c788c3
>
> Did you not get conflicts when rebasing your branch on top of the
> latest version?
Oh, I was testing on Linus' tree when I got the problem, and net was not
merged in Linus' tree yet.
> > Additionally, the patch breaks down the mptcp_init_sched() call into
> > smaller parts, with the RCU read lock only covering the specific call to
> > mptcp_sched_find(). This helps minimize the critical section, reducing
> > the time during which RCU grace periods are blocked.
>
> I agree with Eric (thank you for the review!): this creates other issues.
Let me comment there.
>
> > The mptcp_sched_list_lock is not held in this case, and it is not clear
> > if it is necessary.
>
> It is not needed, the list is not modified, only read with RCU.
Thanks
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net] mptcp: Ensure RCU read lock is held when calling mptcp_sched_find()
2024-10-30 14:18 ` Eric Dumazet
@ 2024-10-30 15:05 ` Breno Leitao
2024-10-30 15:37 ` Eric Dumazet
0 siblings, 1 reply; 6+ messages in thread
From: Breno Leitao @ 2024-10-30 15:05 UTC (permalink / raw)
To: Eric Dumazet
Cc: kuba, horms, davem, pabeni, Matthieu Baerts, Mat Martineau,
Geliang Tang, netdev, linux-kernel, vlad.wing, max, kernel-team,
aehkn, stable, open list:NETWORKING [MPTCP]
Hello Eric,
On Wed, Oct 30, 2024 at 03:18:14PM +0100, Eric Dumazet wrote:
> On Wed, Oct 30, 2024 at 3:02 PM Breno Leitao <leitao@debian.org> wrote:
> >
> > The mptcp_sched_find() function must be called with the RCU read lock
> > held, as it accesses RCU-protected data structures. This requirement was
> > not properly enforced in the mptcp_init_sock() function, leading to a
> > RCU list traversal in a non-reader section error when
> > CONFIG_PROVE_RCU_LIST is enabled.
> >
> > net/mptcp/sched.c:44 RCU-list traversed in non-reader section!!
> >
> > Fix it by acquiring the RCU read lock before calling the
> > mptcp_sched_find() function. This ensures that the function is invoked
> > with the necessary RCU protection in place, as it accesses RCU-protected
> > data structures.
> >
> > Additionally, the patch breaks down the mptcp_init_sched() call into
> > smaller parts, with the RCU read lock only covering the specific call to
> > mptcp_sched_find(). This helps minimize the critical section, reducing
> > the time during which RCU grace periods are blocked.
> >
> > The mptcp_sched_list_lock is not held in this case, and it is not clear
> > if it is necessary.
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > Fixes: 1730b2b2c5a5 ("mptcp: add sched in mptcp_sock")
> > Cc: stable@vger.kernel.org
> > ---
> > net/mptcp/protocol.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> > index 6d0e201c3eb2..8ece630f80d4 100644
> > --- a/net/mptcp/protocol.c
> > +++ b/net/mptcp/protocol.c
> > @@ -2854,6 +2854,7 @@ static void mptcp_ca_reset(struct sock *sk)
> > static int mptcp_init_sock(struct sock *sk)
> > {
> > struct net *net = sock_net(sk);
> > + struct mptcp_sched_ops *sched;
> > int ret;
> >
> > __mptcp_init_sock(sk);
> > @@ -2864,8 +2865,10 @@ static int mptcp_init_sock(struct sock *sk)
> > if (unlikely(!net->mib.mptcp_statistics) && !mptcp_mib_alloc(net))
> > return -ENOMEM;
> >
> > - ret = mptcp_init_sched(mptcp_sk(sk),
> > - mptcp_sched_find(mptcp_get_scheduler(net)));
> > + rcu_read_lock();
> > + sched = mptcp_sched_find(mptcp_get_scheduler(net));
> > + rcu_read_unlock();
>
> You are silencing the warning, but a potential UAF remains.
>
> sched could have been freed already, it is illegal to deref it.
Thanks. I got the impression that the scheduler list was append-only,
and the entries were never freed.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net] mptcp: Ensure RCU read lock is held when calling mptcp_sched_find()
2024-10-30 15:05 ` Breno Leitao
@ 2024-10-30 15:37 ` Eric Dumazet
0 siblings, 0 replies; 6+ messages in thread
From: Eric Dumazet @ 2024-10-30 15:37 UTC (permalink / raw)
To: Breno Leitao
Cc: kuba, horms, davem, pabeni, Matthieu Baerts, Mat Martineau,
Geliang Tang, netdev, linux-kernel, vlad.wing, max, kernel-team,
aehkn, stable, open list:NETWORKING [MPTCP]
On Wed, Oct 30, 2024 at 4:05 PM Breno Leitao <leitao@debian.org> wrote:
> Thanks. I got the impression that the scheduler list was append-only,
> and the entries were never freed.
mptcp_unregister_scheduler() is there, and could be used at some point.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-10-30 15:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-10-30 14:02 [PATCH net] mptcp: Ensure RCU read lock is held when calling mptcp_sched_find() Breno Leitao
2024-10-30 14:18 ` Eric Dumazet
2024-10-30 15:05 ` Breno Leitao
2024-10-30 15:37 ` Eric Dumazet
2024-10-30 14:45 ` Matthieu Baerts
2024-10-30 15:01 ` Breno Leitao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®