mbox series

[RFC,0/1] Fix KASAN: slab-out-of-bounds Read in sk_psock_get

Message ID 20220713063204.6294-1-khalid.masum.92@gmail.com
Headers show
Series Fix KASAN: slab-out-of-bounds Read in sk_psock_get | expand

Message

Khalid Masum July 13, 2022, 6:32 a.m. UTC 
Using size of sk_psock as the size for kcm_psock_cache size no longer
reproduces the issue. There might be a better way to solve this issue
though so I would like to ask for feedback.

Reported-and-tested-by: syzbot+1fa91bcd05206ff8cbb5@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=1fa91bcd05206ff8cbb5

Khalid Masum (1):
  net: kcm: Use sk_psock size for kcm_psock_cache

 net/kcm/kcmsock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Greg Kroah-Hartman July 13, 2022, 6:37 a.m. UTC | #1 
On Wed, Jul 13, 2022 at 12:32:04PM +0600, Khalid Masum wrote:
> `struct sock` has a member `sk_user_data`, which got its memory allocated
> in `kcm_attach` by `kcm_psock_cache` with the size of `kcm_psock`. Which
> is not enough when the member is used as `sk_psock` causing out of bound
> read.
> 
> Use `sk_psock` size to allocate memory instead for `sk_user_data`.
> 
> Reported-by: syzbot+1fa91bcd05206ff8cbb5@syzkaller.appspotmail.com
> Signed-off-by: Khalid Masum <khalid.masum.92@gmail.com>
> ---
>  net/kcm/kcmsock.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

What commit id does this fix?

thanks,

greg k-h
Jakub Kicinski July 13, 2022, 6:16 p.m. UTC | #2 
On Wed, 13 Jul 2022 12:32:04 +0600 Khalid Masum wrote:
> `struct sock` has a member `sk_user_data`, which got its memory allocated
> in `kcm_attach` by `kcm_psock_cache` with the size of `kcm_psock`. Which
> is not enough when the member is used as `sk_psock` causing out of bound
> read.
> 
> Use `sk_psock` size to allocate memory instead for `sk_user_data`.
> 
> Reported-by: syzbot+1fa91bcd05206ff8cbb5@syzkaller.appspotmail.com
> Signed-off-by: Khalid Masum <khalid.masum.92@gmail.com>

Odd CC list, it looks like a netdev problem but netdev@ is not copied.

We had an other parson looking at this on netdev. Is this happening
when legit kernel socket gets mixed with BPF sockmap?

Does this fix work?

https://lore.kernel.org/netdev/165030056960.5073.6664402939918720250.stgit@oracle-102.nfsv4.dev/