| Message ID | 20250331091532.224982-1-edumazet@google.com (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net] sctp: add mutual exclusion in proc_sctp_do_udp_port() | expand |
On Mon, Mar 31, 2025 at 5:15 AM Eric Dumazet <edumazet@google.com> wrote: > > We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start() > or risk a crash as syzbot reported: > > Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI > KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] > CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full) > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 > RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653 > Call Trace: > <TASK> > udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 > sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 > proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 > proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 > iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 > do_splice_from fs/splice.c:935 [inline] > direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 > splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 > do_splice_direct_actor fs/splice.c:1201 [inline] > do_splice_direct+0x174/0x240 fs/splice.c:1227 > do_sendfile+0xafd/0xe50 fs/read_write.c:1368 > __do_sys_sendfile64 fs/read_write.c:1429 [inline] > __se_sys_sendfile64 fs/read_write.c:1415 [inline] > __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > > Fixes: 046c052b475e ("sctp: enable udp tunneling socks") > Reported-by: syzbot+fae49d997eb56fa7c74d@syzkaller.appspotmail.com > Closes: https://lore.kernel.org/netdev/67ea5c01.050a0220.1547ec.012b.GAE@google.com/T/#u > Signed-off-by: Eric Dumazet <edumazet@google.com> > Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> > Cc: Xin Long <lucien.xin@gmail.com> > --- > net/sctp/sysctl.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c > index 8e1e97be4df79f3245e2bbbeb0a75841abc67f58..ee3eac338a9deef064f273e29bb59b057835d3f1 100644 > --- a/net/sctp/sysctl.c > +++ b/net/sctp/sysctl.c > @@ -525,6 +525,8 @@ static int proc_sctp_do_auth(const struct ctl_table *ctl, int write, > return ret; > } > > +static DEFINE_MUTEX(sctp_sysctl_mutex); > + > static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > void *buffer, size_t *lenp, loff_t *ppos) > { > @@ -549,6 +551,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > if (new_value > max || new_value < min) > return -EINVAL; > > + mutex_lock(&sctp_sysctl_mutex); > net->sctp.udp_port = new_value; > sctp_udp_sock_stop(net); > if (new_value) { > @@ -561,6 +564,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > lock_sock(sk); > sctp_sk(sk)->udp_port = htons(net->sctp.udp_port); > release_sock(sk); > + mutex_unlock(&sctp_sysctl_mutex); > } > > return ret; > -- > 2.49.0.472.ge94155a9ec-goog > Instead of introducing a new lock for this, wouldn't be better to just move up `lock_sock(sk)` a little bit?
On Mon, Mar 31, 2025 at 5:54 PM Xin Long <lucien.xin@gmail.com> wrote: > > On Mon, Mar 31, 2025 at 5:15 AM Eric Dumazet <edumazet@google.com> wrote: > > > > We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start() > > or risk a crash as syzbot reported: > > > > Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI > > KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] > > CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full) > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 > > RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653 > > Call Trace: > > <TASK> > > udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 > > sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 > > proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 > > proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 > > iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 > > do_splice_from fs/splice.c:935 [inline] > > direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 > > splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 > > do_splice_direct_actor fs/splice.c:1201 [inline] > > do_splice_direct+0x174/0x240 fs/splice.c:1227 > > do_sendfile+0xafd/0xe50 fs/read_write.c:1368 > > __do_sys_sendfile64 fs/read_write.c:1429 [inline] > > __se_sys_sendfile64 fs/read_write.c:1415 [inline] > > __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 > > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > > > > Fixes: 046c052b475e ("sctp: enable udp tunneling socks") > > Reported-by: syzbot+fae49d997eb56fa7c74d@syzkaller.appspotmail.com > > Closes: https://lore.kernel.org/netdev/67ea5c01.050a0220.1547ec.012b.GAE@google.com/T/#u > > Signed-off-by: Eric Dumazet <edumazet@google.com> > > Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> > > Cc: Xin Long <lucien.xin@gmail.com> > > --- > > net/sctp/sysctl.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c > > index 8e1e97be4df79f3245e2bbbeb0a75841abc67f58..ee3eac338a9deef064f273e29bb59b057835d3f1 100644 > > --- a/net/sctp/sysctl.c > > +++ b/net/sctp/sysctl.c > > @@ -525,6 +525,8 @@ static int proc_sctp_do_auth(const struct ctl_table *ctl, int write, > > return ret; > > } > > > > +static DEFINE_MUTEX(sctp_sysctl_mutex); > > + > > static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > void *buffer, size_t *lenp, loff_t *ppos) > > { > > @@ -549,6 +551,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > if (new_value > max || new_value < min) > > return -EINVAL; > > > > + mutex_lock(&sctp_sysctl_mutex); > > net->sctp.udp_port = new_value; > > sctp_udp_sock_stop(net); > > if (new_value) { > > @@ -561,6 +564,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > lock_sock(sk); > > sctp_sk(sk)->udp_port = htons(net->sctp.udp_port); > > release_sock(sk); > > + mutex_unlock(&sctp_sysctl_mutex); > > } > > > > return ret; > > -- > > 2.49.0.472.ge94155a9ec-goog > > > Instead of introducing a new lock for this, wouldn't be better to just > move up `lock_sock(sk)` a little bit? It depends if calling synchronize_rcu() two times while holding the socket lock is ok or not ? What is the issue about using a separate mutex ?
On Mon, 31 Mar 2025 18:11:38 +0200 Eric Dumazet <edumazet@google.com> wrote: > On Mon, Mar 31, 2025 at 5:54 PM Xin Long <lucien.xin@gmail.com> wrote: > > > > On Mon, Mar 31, 2025 at 5:15 AM Eric Dumazet <edumazet@google.com> wrote: > > > > > > We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start() > > > or risk a crash as syzbot reported: > > > > > > Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI > > > KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] > > > CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full) > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 > > > RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653 > > > Call Trace: > > > <TASK> > > > udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 > > > sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 > > > proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 > > > proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 > > > iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 > > > do_splice_from fs/splice.c:935 [inline] > > > direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 > > > splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 > > > do_splice_direct_actor fs/splice.c:1201 [inline] > > > do_splice_direct+0x174/0x240 fs/splice.c:1227 > > > do_sendfile+0xafd/0xe50 fs/read_write.c:1368 > > > __do_sys_sendfile64 fs/read_write.c:1429 [inline] > > > __se_sys_sendfile64 fs/read_write.c:1415 [inline] > > > __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 > > > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > > > > > > Fixes: 046c052b475e ("sctp: enable udp tunneling socks") > > > Reported-by: syzbot+fae49d997eb56fa7c74d@syzkaller.appspotmail.com > > > Closes: https://lore.kernel.org/netdev/67ea5c01.050a0220.1547ec.012b.GAE@google.com/T/#u > > > Signed-off-by: Eric Dumazet <edumazet@google.com> > > > Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> > > > Cc: Xin Long <lucien.xin@gmail.com> > > > --- > > > net/sctp/sysctl.c | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c > > > index 8e1e97be4df79f3245e2bbbeb0a75841abc67f58..ee3eac338a9deef064f273e29bb59b057835d3f1 100644 > > > --- a/net/sctp/sysctl.c > > > +++ b/net/sctp/sysctl.c > > > @@ -525,6 +525,8 @@ static int proc_sctp_do_auth(const struct ctl_table *ctl, int write, > > > return ret; > > > } > > > > > > +static DEFINE_MUTEX(sctp_sysctl_mutex); > > > + > > > static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > > void *buffer, size_t *lenp, loff_t *ppos) > > > { > > > @@ -549,6 +551,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > > if (new_value > max || new_value < min) > > > return -EINVAL; > > > > > > + mutex_lock(&sctp_sysctl_mutex); > > > net->sctp.udp_port = new_value; > > > sctp_udp_sock_stop(net); > > > if (new_value) { > > > @@ -561,6 +564,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > > lock_sock(sk); > > > sctp_sk(sk)->udp_port = htons(net->sctp.udp_port); > > > release_sock(sk); > > > + mutex_unlock(&sctp_sysctl_mutex); > > > } > > > > > > return ret; > > > -- > > > 2.49.0.472.ge94155a9ec-goog > > > > > Instead of introducing a new lock for this, wouldn't be better to just > > move up `lock_sock(sk)` a little bit? > > It depends if calling synchronize_rcu() two times while holding the > socket lock is ok or not ? > > What is the issue about using a separate mutex ? > Don't they need locking against a different path that is using the socket? Not only against concurrent accesses to the sysctl? Presuming the crash was because of the net->sctp.udp4_sock = NULL assignment in sock_stop(), if 'min' is zero allowing 'new_value' zero then the pointer is left NULL. IIRC sctp_sk(sk) is fixed, so the sock_lock() doesn't do much apart from stop some unlikely 'data tearing'. David
On Mon, Mar 31, 2025 at 12:11 PM Eric Dumazet <edumazet@google.com> wrote: > > On Mon, Mar 31, 2025 at 5:54 PM Xin Long <lucien.xin@gmail.com> wrote: > > > > On Mon, Mar 31, 2025 at 5:15 AM Eric Dumazet <edumazet@google.com> wrote: > > > > > > We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start() > > > or risk a crash as syzbot reported: > > > > > > Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI > > > KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] > > > CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full) > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 > > > RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653 > > > Call Trace: > > > <TASK> > > > udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 > > > sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 > > > proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 > > > proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 > > > iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 > > > do_splice_from fs/splice.c:935 [inline] > > > direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 > > > splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 > > > do_splice_direct_actor fs/splice.c:1201 [inline] > > > do_splice_direct+0x174/0x240 fs/splice.c:1227 > > > do_sendfile+0xafd/0xe50 fs/read_write.c:1368 > > > __do_sys_sendfile64 fs/read_write.c:1429 [inline] > > > __se_sys_sendfile64 fs/read_write.c:1415 [inline] > > > __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 > > > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > > > > > > Fixes: 046c052b475e ("sctp: enable udp tunneling socks") > > > Reported-by: syzbot+fae49d997eb56fa7c74d@syzkaller.appspotmail.com > > > Closes: https://lore.kernel.org/netdev/67ea5c01.050a0220.1547ec.012b.GAE@google.com/T/#u > > > Signed-off-by: Eric Dumazet <edumazet@google.com> > > > Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> > > > Cc: Xin Long <lucien.xin@gmail.com> > > > --- > > > net/sctp/sysctl.c | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c > > > index 8e1e97be4df79f3245e2bbbeb0a75841abc67f58..ee3eac338a9deef064f273e29bb59b057835d3f1 100644 > > > --- a/net/sctp/sysctl.c > > > +++ b/net/sctp/sysctl.c > > > @@ -525,6 +525,8 @@ static int proc_sctp_do_auth(const struct ctl_table *ctl, int write, > > > return ret; > > > } > > > > > > +static DEFINE_MUTEX(sctp_sysctl_mutex); > > > + > > > static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > > void *buffer, size_t *lenp, loff_t *ppos) > > > { > > > @@ -549,6 +551,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > > if (new_value > max || new_value < min) > > > return -EINVAL; > > > > > > + mutex_lock(&sctp_sysctl_mutex); > > > net->sctp.udp_port = new_value; > > > sctp_udp_sock_stop(net); > > > if (new_value) { > > > @@ -561,6 +564,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > > lock_sock(sk); > > > sctp_sk(sk)->udp_port = htons(net->sctp.udp_port); > > > release_sock(sk); > > > + mutex_unlock(&sctp_sysctl_mutex); > > > } > > > > > > return ret; > > > -- > > > 2.49.0.472.ge94155a9ec-goog > > > > > Instead of introducing a new lock for this, wouldn't be better to just > > move up `lock_sock(sk)` a little bit? > > It depends if calling synchronize_rcu() two times while holding the > socket lock is ok or not ? hm, It doesn't sound normal, although this ctl_sock only handles the out-of-blue packets. > > What is the issue about using a separate mutex ? no issue, just don't want to introduce a new lock for this only. Acked-by: Xin Long <lucien.xin@gmail.com>
On Mon, Mar 31, 2025 at 2:50 PM David Laight <david.laight.linux@gmail.com> wrote: > > On Mon, 31 Mar 2025 18:11:38 +0200 > Eric Dumazet <edumazet@google.com> wrote: > > > On Mon, Mar 31, 2025 at 5:54 PM Xin Long <lucien.xin@gmail.com> wrote: > > > > > > On Mon, Mar 31, 2025 at 5:15 AM Eric Dumazet <edumazet@google.com> wrote: > > > > > > > > We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start() > > > > or risk a crash as syzbot reported: > > > > > > > > Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI > > > > KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] > > > > CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full) > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 > > > > RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653 > > > > Call Trace: > > > > <TASK> > > > > udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 > > > > sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 > > > > proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 > > > > proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 > > > > iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 > > > > do_splice_from fs/splice.c:935 [inline] > > > > direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 > > > > splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 > > > > do_splice_direct_actor fs/splice.c:1201 [inline] > > > > do_splice_direct+0x174/0x240 fs/splice.c:1227 > > > > do_sendfile+0xafd/0xe50 fs/read_write.c:1368 > > > > __do_sys_sendfile64 fs/read_write.c:1429 [inline] > > > > __se_sys_sendfile64 fs/read_write.c:1415 [inline] > > > > __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 > > > > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > > > > > > > > Fixes: 046c052b475e ("sctp: enable udp tunneling socks") > > > > Reported-by: syzbot+fae49d997eb56fa7c74d@syzkaller.appspotmail.com > > > > Closes: https://lore.kernel.org/netdev/67ea5c01.050a0220.1547ec.012b.GAE@google.com/T/#u > > > > Signed-off-by: Eric Dumazet <edumazet@google.com> > > > > Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> > > > > Cc: Xin Long <lucien.xin@gmail.com> > > > > --- > > > > net/sctp/sysctl.c | 4 ++++ > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c > > > > index 8e1e97be4df79f3245e2bbbeb0a75841abc67f58..ee3eac338a9deef064f273e29bb59b057835d3f1 100644 > > > > --- a/net/sctp/sysctl.c > > > > +++ b/net/sctp/sysctl.c > > > > @@ -525,6 +525,8 @@ static int proc_sctp_do_auth(const struct ctl_table *ctl, int write, > > > > return ret; > > > > } > > > > > > > > +static DEFINE_MUTEX(sctp_sysctl_mutex); > > > > + > > > > static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > > > void *buffer, size_t *lenp, loff_t *ppos) > > > > { > > > > @@ -549,6 +551,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > > > if (new_value > max || new_value < min) > > > > return -EINVAL; > > > > > > > > + mutex_lock(&sctp_sysctl_mutex); > > > > net->sctp.udp_port = new_value; > > > > sctp_udp_sock_stop(net); > > > > if (new_value) { > > > > @@ -561,6 +564,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, > > > > lock_sock(sk); > > > > sctp_sk(sk)->udp_port = htons(net->sctp.udp_port); > > > > release_sock(sk); > > > > + mutex_unlock(&sctp_sysctl_mutex); > > > > } > > > > > > > > return ret; > > > > -- > > > > 2.49.0.472.ge94155a9ec-goog > > > > > > > Instead of introducing a new lock for this, wouldn't be better to just > > > move up `lock_sock(sk)` a little bit? > > > > It depends if calling synchronize_rcu() two times while holding the > > socket lock is ok or not ? > > > > What is the issue about using a separate mutex ? > > > > Don't they need locking against a different path that is using the socket? > Not only against concurrent accesses to the sysctl? > Hi Davide, The lock is used to protect the variable 'net->sctp.udp4_sock', and there are no other paths accessing it. The udp socket is created to listen on a specific port for receiving only, there's no need to access net->sctp.udp4_sock in sctp data path. Thanks. > Presuming the crash was because of the net->sctp.udp4_sock = NULL > assignment in sock_stop(), if 'min' is zero allowing 'new_value' zero > then the pointer is left NULL. > > IIRC sctp_sk(sk) is fixed, so the sock_lock() doesn't do much apart > from stop some unlikely 'data tearing'. > > David
diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c index 8e1e97be4df79f3245e2bbbeb0a75841abc67f58..ee3eac338a9deef064f273e29bb59b057835d3f1 100644 --- a/net/sctp/sysctl.c +++ b/net/sctp/sysctl.c @@ -525,6 +525,8 @@ static int proc_sctp_do_auth(const struct ctl_table *ctl, int write, return ret; } +static DEFINE_MUTEX(sctp_sysctl_mutex); + static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, void *buffer, size_t *lenp, loff_t *ppos) { @@ -549,6 +551,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, if (new_value > max || new_value < min) return -EINVAL; + mutex_lock(&sctp_sysctl_mutex); net->sctp.udp_port = new_value; sctp_udp_sock_stop(net); if (new_value) { @@ -561,6 +564,7 @@ static int proc_sctp_do_udp_port(const struct ctl_table *ctl, int write, lock_sock(sk); sctp_sk(sk)->udp_port = htons(net->sctp.udp_port); release_sock(sk); + mutex_unlock(&sctp_sysctl_mutex); } return ret;
We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start() or risk a crash as syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653 Call Trace: <TASK> udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 do_splice_from fs/splice.c:935 [inline] direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 do_splice_direct_actor fs/splice.c:1201 [inline] do_splice_direct+0x174/0x240 fs/splice.c:1227 do_sendfile+0xafd/0xe50 fs/read_write.c:1368 __do_sys_sendfile64 fs/read_write.c:1429 [inline] __se_sys_sendfile64 fs/read_write.c:1415 [inline] __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Reported-by: syzbot+fae49d997eb56fa7c74d@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/67ea5c01.050a0220.1547ec.012b.GAE@google.com/T/#u Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: Xin Long <lucien.xin@gmail.com> --- net/sctp/sysctl.c | 4 ++++ 1 file changed, 4 insertions(+)