On 10/9/24 11:46, Jakub Sitnicki wrote:
> That's curious. We don't override the proto::sendmsg callback for
> protocols which don't support sk_msg redirects, like UDP:
>
> https://elixir.bootlin.com/linux/v6.12-rc2/source/net/ipv4/udp_bpf.c#L114
>
> The packet should get delivered to the peer soc
On 9/27/24 11:15, Jakub Sitnicki wrote:
> On Fri, Sep 27, 2024 at 12:54 AM +02, Michal Luczaj wrote:
>> ...
>> Here's a follow up: my guess is that some checks are missing. I'm not sure
>> if it's the best approach, but this fixes things for me:
>
> So yo
On 8/19/24 22:05, Jakub Sitnicki wrote:
> On Wed, Aug 14, 2024 at 06:14 PM +02, Michal Luczaj wrote:
>> On 8/6/24 19:45, Jakub Sitnicki wrote:
>>> On Tue, Aug 06, 2024 at 07:18 PM +02, Michal Luczaj wrote:
>>>> Great, thanks for the review. With this completed, I gues
On 9/24/24 12:25, Michal Luczaj wrote:
> On 8/19/24 22:05, Jakub Sitnicki wrote:
>> On Wed, Aug 14, 2024 at 06:14 PM +02, Michal Luczaj wrote:
>>> On 8/6/24 19:45, Jakub Sitnicki wrote:
>>>> On Tue, Aug 06, 2024 at 07:18 PM +02, Michal Luczaj wrote:
>>>>
s.com/syzbot-assets/944ca63002c1/vmlinux-c2933b2b.xz
> kernel image:
> https://storage.googleapis.com/syzbot-assets/30748115bf0b/bzImage-c2933b2b.xz
>
> The issue was bisected to:
>
> commit fcdd2242c0231032fc84e1404315c245ae56322a
> Author: Michal Luczaj
> Date: Tue Jan
s.com/syzbot-assets/944ca63002c1/vmlinux-c2933b2b.xz
> kernel image:
> https://storage.googleapis.com/syzbot-assets/30748115bf0b/bzImage-c2933b2b.xz
>
> The issue was bisected to:
>
> commit fcdd2242c0231032fc84e1404315c245ae56322a
> Author: Michal Luczaj
> Date: Tue Jan 28 1
On 2/4/25 11:04, Stefano Garzarella wrote:
> On Tue, 4 Feb 2025 at 10:59, Stefano Garzarella wrote:
>> On Tue, Feb 04, 2025 at 01:38:50AM +0100, Michal Luczaj wrote:
>>> ...
>>> I'm not sure this is the most elegant code (sock_orphan(sk) sets SOCK_DEAD
>>&
On 1/21/25 18:30, Luigi Leonardi wrote:
> On Thu, Jan 09, 2025 at 02:34:28PM +0100, Michal Luczaj wrote:
>> FWIW, I've tried simplifying Hyunwoo's repro to toy with some tests.
>> Ended
>> up with
>>
>> ```
>>from threading import *
>>from so
On 1/16/25 09:57, Stefano Garzarella wrote:
> On Tue, Jan 14, 2025 at 05:31:08PM +0100, Michal Luczaj wrote:
>>> ...
>>> Maybe we need to look better at the release, and prevent it from
>>> removing the socket from the lists as you suggested, maybe adding a
>&
On 1/10/25 09:35, Stefano Garzarella wrote:
> If the socket has been de-assigned or assigned to another transport,
> we must discard any packets received because they are not expected
> and would cause issues when we access vsk->transport.
>
> A possible scenario is described by Hyunwoo Kim in the
On 1/13/25 16:01, Stefano Garzarella wrote:
> On Mon, Jan 13, 2025 at 02:51:58PM +0100, Michal Luczaj wrote:
>> On 1/13/25 12:05, Stefano Garzarella wrote:
>>> ...
>>> An alternative approach, which would perhaps allow us to avoid all this,
>>> is to re-insert
On 1/13/25 10:07, Stefano Garzarella wrote:
> On Mon, 13 Jan 2025 at 09:57, Stefano Garzarella wrote:
>> On Sun, Jan 12, 2025 at 11:42:30PM +0100, Michal Luczaj wrote:
>
> [...]
>
>>>
>>> So, if I get this right:
>>> 1. vsock_create() (refcnt=1)
On 1/13/25 12:05, Stefano Garzarella wrote:
> On Mon, Jan 13, 2025 at 11:12:52AM +0100, Michal Luczaj wrote:
>> On 1/13/25 10:07, Stefano Garzarella wrote:
>>> On Mon, 13 Jan 2025 at 09:57, Stefano Garzarella
>>> wrote:
>>>> On Sun, Jan 12, 2025 a
On 1/14/25 11:16, Stefano Garzarella wrote:
> On Tue, Jan 14, 2025 at 01:09:24AM +0100, Michal Luczaj wrote:
>> On 1/13/25 16:01, Stefano Garzarella wrote:
>>> On Mon, Jan 13, 2025 at 02:51:58PM +0100, Michal Luczaj wrote:
>>>> On 1/13/25 12:05, Stefano Garzar
0
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> So we need to check the `vsk->transport` in vsock_bpf_recvmsg(),
> especially for connected sockets (stream/seqpacket) as we already
> do in __vsock_connectible_recvmsg().
>
> Fixes: 634f1a7110b4 ("vsock: suppo
On 1/9/25 14:42, Stefano Garzarella wrote:
> On Thu, Jan 09, 2025 at 02:34:28PM +0100, Michal Luczaj wrote:
>> ...
>> That said, when I apply this patch, but drop the `sk->sk_state !=
>> TCP_LISTEN &&`: no more splats.
>
> We can't drop `sk->sk_s
On 1/8/25 19:06, Stefano Garzarella wrote:
> If the socket has been de-assigned or assigned to another transport,
> we must discard any packets received because they are not expected
> and would cause issues when we access vsk->transport.
>
> A possible scenario is described by Hyunwoo Kim in the
of relying solely on the state of
vsk->transport, tell sockmap to only allow those representing established
connections. This aligns with the behaviour for AF_INET and AF_UNIX.
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Signed-off-by: Michal Luczaj
---
net/core/sock_map.c |
In the spirit of commit 91751e248256 ("vsock: prevent null-ptr-deref in
vsock_*[has_data|has_space]"), armorize the "impossible" cases with a
warning.
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Signed-off-by: Michal Luczaj
---
net/vmw_vsock/af_vsock.c | 3 +++
creating a socket pair and attempting to replace a
close()d one with its peer. Since, due to a recent change, sockmap does not
allow updating index with a non-established connectible vsock, redo it with
a freshly established one.
Signed-off-by: Michal Luczaj
---
.../selftests/bpf/prog_tests/sockm
ready connected (no risk of transport being dropped or reassigned). At
the same time straight reject the listeners (vsock listening sockets do not
carry any transport anyway). This way BPF does not have to worry about
vsk->transport becoming NULL.
Signed-off-by: Michal Luczaj
---
Michal Luczaj
unimplemented vsock_transport::readskb() callback, making it unsupported by
BPF/sockmap.
Signed-off-by: Michal Luczaj
---
.../selftests/bpf/prog_tests/sockmap_basic.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/tools/testing/selftests/bpf/prog_tests
> ...
> Another design detail is that listening vsocks are not supposed to have any
> transport assigned at all. Which implies they are not supported by the
> sockmap. But this is complicated by the fact that a socket, before
> switching to TCP_LISTEN, may have had some transport assigned during a
On 2/13/25 12:58, Michal Luczaj wrote:
> ...
> This does not test datagram vsocks. Even though it hardly matters. VMCI is
> the only transport that features VSOCK_TRANSPORT_F_DGRAM, but it has an
> unimplemented vsock_transport::readskb() callback, making it un
On 2/17/25 11:59, Stefano Garzarella wrote:
> On Thu, Feb 13, 2025 at 12:58:50PM +0100, Michal Luczaj wrote:
>> In the spirit of commit 91751e248256 ("vsock: prevent null-ptr-deref in
>> vsock_*[has_data|has_space]"), armorize the "impossible" cases with a
&g
On 2/28/25 06:51, Jiayuan Chen wrote:
> ...
> static void sk_psock_verdict_data_ready(struct sock *sk)
> {
> - struct socket *sock = sk->sk_socket;
> + struct socket *sock;
> const struct proto_ops *ops;
> int copied;
>
> trace_sk_data_ready(sk);
>
> + /* We need
org/netdev/Z2LvdTTQR7dBmPb5@v4bel-B760M-AORUS-ELITE-AX/
>
> Suggested-by: Michal Luczaj
> Signed-off-by: Luigi Leonardi
> ---
I think the credit should be given to Hyunwoo Kim, not me.
Thanks though,
Michal
On 3/10/25 12:36, Jiayuan Chen wrote:
> March 7, 2025 at 5:45 PM, "Michal Luczaj" wrote:
> ...
>> BTW, lockdep (CONFIG_LOCKDEP=y) complains about calling AF_UNIX's
>> read_skb() under RCU read lock.
>>
> My environment also has LOCKDEP enabled, but I didn
IP: 0010:vsock_bpf_recvmsg+0xb43/0xe00
sock_recvmsg+0x1b2/0x220
__sys_recvfrom+0x190/0x270
__x64_sys_recvfrom+0xdc/0x1b0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Reviewed-by: Stefano Garzarella
Signed-off-by: Micha
signal_pending
state = SS_UNCONNECTED
connect
transport = NULL
vsock_bpf_recvmsg
WARN_ON_ONCE(!vsk->transport)
Signed-off-by: Michal Luczaj
---
.../selftests/bpf/prog_tests/sockmap_basic.c | 97 ++
1 f
_recvmsg+0xb55/0xe00
sock_recvmsg+0x1b2/0x220
__sys_recvfrom+0x190/0x270
__x64_sys_recvfrom+0xdc/0x1b0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Signed-off-by: Michal Luczaj
---
net/vmw_vsoc
_recvmsg+0xb55/0xe00
sock_recvmsg+0x1b2/0x220
__sys_recvfrom+0x190/0x270
__x64_sys_recvfrom+0xdc/0x1b0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Signed-off-by: Michal Luczaj
---
net/vmw_vsoc
IP: 0010:vsock_bpf_recvmsg+0xb43/0xe00
sock_recvmsg+0x1b2/0x220
__sys_recvfrom+0x190/0x270
__x64_sys_recvfrom+0xdc/0x1b0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Reviewed-by: Stefano Garzarella
Signed-off-by: Micha
TCH 3 fixes a related race. Note that here the race window is rather
difficult to hit and I can't think of an easy way of testing it.
Signed-off-by: Michal Luczaj
---
Changes in v2:
- Handle one more path of tripping the warning
- Add a selftest
- Collect R-b [Stefano]
- Link to v1:
https://lore.
signal_pending
state = SS_UNCONNECTED
connect
transport = NULL
vsock_bpf_recvmsg
WARN_ON_ONCE(!vsk->transport)
Signed-off-by: Michal Luczaj
---
.../selftests/bpf/prog_tests/sockmap_basic.c | 111 +
1 f
On 3/14/25 10:27, Luigi Leonardi wrote:
> Add a new test to ensure that when the transport changes a null pointer
> dereference does not occur[1].
>
> Note that this test does not fail, but it may hang on the client side if
> it triggers a kernel oops.
>
> This works by creating a socket, trying
TCH 3 fixes a related race. Note that selftest in PATCH 2 does test this
code as well, but winning this race variant may take more than 2 seconds,
so I'm not advertising it.
Signed-off-by: Michal Luczaj
---
Changes in v3:
- Selftest: drop unnecessary variable initialization and reorder the calls
On 3/19/25 10:34, Stefano Garzarella wrote:
> On Mon, Mar 17, 2025 at 10:52:25AM +0100, Michal Luczaj wrote:
>> ...
>> -static int vsock_bpf_recvmsg(struct sock *sk, struct msghdr *msg,
>> - size_t len, int flags, int *addr_len)
>> +static int vs
On 3/17/25 09:23, Paolo Abeni wrote:
> On 3/16/25 11:45 PM, Michal Luczaj wrote:
>> Racing signal-interrupted connect() and sockmap update may result in an
>> unconnected (and missing vsock transport) socket in a sockmap.
>>
>> Test spends 2 seconds attem
_recvmsg+0xb55/0xe00
sock_recvmsg+0x1b2/0x220
__sys_recvfrom+0x190/0x270
__x64_sys_recvfrom+0xdc/0x1b0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Signed-off-by: Michal Luczaj
---
net/vmw_vsoc
TCH 3 fixes a related race. Note that selftest in PATCH 2 does test this
code as well, but winning this race variant may take more than 2 seconds,
so I'm not advertising it.
Signed-off-by: Michal Luczaj
---
Changes in v4:
- Selftest: send signal to only our own process
- Link to
signal_pending
state = SS_UNCONNECTED
connect
transport = NULL
vsock_bpf_recvmsg
WARN_ON_ONCE(!vsk->transport)
Signed-off-by: Michal Luczaj
---
.../selftests/bpf/prog_tests/sockmap_basic.c | 99 ++
1 f
IP: 0010:vsock_bpf_recvmsg+0xb43/0xe00
sock_recvmsg+0x1b2/0x220
__sys_recvfrom+0x190/0x270
__x64_sys_recvfrom+0xdc/0x1b0
do_syscall_64+0x93/0x1b0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fixes: 634f1a7110b4 ("vsock: support sockmap")
Reviewed-by: Stefano Garzarella
Signed-off-by: Micha
On 3/19/25 23:18, Cong Wang wrote:
> On Mon, Mar 17, 2025 at 10:52:25AM +0100, Michal Luczaj wrote:
>> Signal delivery during connect() may lead to a disconnect of an already
>> established socket. That involves removing socket from any sockmap and
>> resetting state to SS_
On 3/20/25 21:54, Cong Wang wrote:
> On Thu, Mar 20, 2025 at 01:05:27PM +0100, Michal Luczaj wrote:
>> On 3/19/25 23:18, Cong Wang wrote:
>>> On Mon, Mar 17, 2025 at 10:52:25AM +0100, Michal Luczaj wrote:
>>>> Signal delivery during connect() may lead to a disconnect
45 matches
Mail list logo
