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] [thread-next>] [day] [month] [year] [list]
Message-ID: <e7fc9584-3b69-4cbb-ab45-efb1dc37efdb@linux.dev>
Date: Fri, 12 Sep 2025 15:55:08 -0700
From: "Yanjun.Zhu" <yanjun.zhu@...ux.dev>
To: syzbot <syzbot+b0da83a6c0e2e2bddbd4@...kaller.appspotmail.com>,
 edwards@...dia.com, hdanton@...a.com, jgg@...pe.ca, leon@...nel.org,
 leonro@...dia.com, linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
 syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [rdma?] WARNING in gid_table_release_one (3)



On 9/12/25 3:33 PM, Yanjun.Zhu wrote:
> 
> 
> On 9/12/25 1:01 PM, Yanjun.Zhu wrote:
>>
>>
>> On 9/12/25 12:38 PM, yanjun.zhu wrote:
>>> On 9/11/25 9:42 PM, syzbot wrote:
>>>> syzbot has bisected this issue to:
>>>>
>>>> commit a92fbeac7e94a420b55570c10fe1b90e64da4025
>>>> Author: Leon Romanovsky <leonro@...dia.com>
>>>> Date:   Tue May 28 12:52:51 2024 +0000
>>>>
>>>>      RDMA/cache: Release GID table even if leak is detected
>>>
>>> Maybe this commit just detects ref leaks and reports ref leak.
>>> Even though this commit is reverted, this ref leak still occurs.
>>>
>>> The root cause is not in this commit.
>>>
>>> "
>>> GID entry ref leak for dev syz1 index 2 ref=615
>>> "
>>>
>>> Ref leaks in dev syz1.
>> In this link: https://syzkaller.appspot.com/x/log.txt?x=157dab12580000
>>
>> "
>> [  184.209420][ T6164] infiniband syz1: set active
>> [  184.215960][ T6164] infiniband syz1: added syz_tun
>> [  184.222514][ T6001] veth0_macvtap: entered promiscuous mode
>> [  184.231935][   T42] wlan0: Created IBSS using preconfigured BSSID 
>> 50:50:50:50:50:50
>> [  184.239777][   T42] wlan0: Creating new IBSS network, BSSID 
>> 50:50:50:50:50:50
>> [  184.256962][ T6001] veth1_macvtap: entered promiscuous mode
>> [  184.276479][ T6164] syz1: rxe_create_cq: returned err = -12 < -- 
>> rxe_create_cq failed, the test should not continue.
>>
>> [  184.288430][ T6008] veth0_vlan: entered promiscuous mode
>> "
>>
>> err = -12, is -ENOMEM.
> 
> "
> [  139.009314][ T6730] infiniband syz1: added syz_tun
> [  139.015974][ T6730] rdma_rxe: vmalloc_user failed, buf_size: 131456, 
> num_slots: 1024, elem_size: 128
> [  139.016142][ T6730] syz1: rxe_cq_from_init: unable to create cq
> "

The above logs are in the link: 
https://syzkaller.appspot.com/x/log.txt?x=144a9934580000

Please check it.

Zhu Yanjun

> 
>  From the above logs, vmalloc_user() fails when trying to allocate 
> 131,456 bytes of memory.
> 
> Is there a specific limit on vmalloc allocations in this test case?
> 
> Also, what is the size of memory available on this machine? (Hardware 
> name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
> 08/18/2025)
> 
> Thanks,
> Zhu Yanjun
> 
>>
>> It means that memory allocation fails.
>>
>> Zhu Yanjun
>>
>>>
>>> Zhu Yanjun
>>>
>>>>
>>>> bisection log:  https://syzkaller.appspot.com/x/bisect.txt? 
>>>> x=13fc9642580000
>>>> start commit:   5f540c4aade9 Add linux-next specific files for 20250910
>>>> git tree:       linux-next
>>>> final oops:     https://syzkaller.appspot.com/x/report.txt? 
>>>> x=10029642580000
>>>> console output: https://syzkaller.appspot.com/x/log.txt? 
>>>> x=17fc9642580000
>>>> kernel config:  https://syzkaller.appspot.com/x/.config? 
>>>> x=5ed48faa2cb8510d
>>>> dashboard link: https://syzkaller.appspot.com/bug? 
>>>> extid=b0da83a6c0e2e2bddbd4
>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz? 
>>>> x=15b52362580000
>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c? 
>>>> x=16b41642580000
>>>>
>>>> Reported-by: syzbot+b0da83a6c0e2e2bddbd4@...kaller.appspotmail.com
>>>> Fixes: a92fbeac7e94 ("RDMA/cache: Release GID table even if leak is 
>>>> detected")
>>>>
>>>> For information about bisection process see: https://goo.gl/ 
>>>> tpsmEJ#bisection
>>>
>>
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ