Syzkaller reports memory leak issue at gsmld_attach_gsm() in
5.10 stable releases. The reproducer injects the memory allocation
errors to tty_register_device(); as a result, tty_kref_get() isn't called
after this error, which leads to tty_struct leak.
The issue has been fixed by the following patches that can be cleanly
applied to the 5.10 branch.

Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller

On Tue, Dec 12, 2023 at 11:17:21AM +0000, Gavrilov Ilia wrote:
> Syzkaller reports memory leak issue at gsmld_attach_gsm() in
> 5.10 stable releases. The reproducer injects the memory allocation
> errors to tty_register_device(); as a result, tty_kref_get() isn't called
> after this error, which leads to tty_struct leak.
> The issue has been fixed by the following patches that can be cleanly
> applied to the 5.10 branch.
> 
> Found by InfoTeCS on behalf of Linux Verification Center
> (linuxtesting.org) with Syzkaller

Do you actually have any hardware for this protocol running on the
5.10.y kernel?  How was this tested?  Why was just this specific set of
patches picked to be backported?

thanks,

greg k-h

On 12/12/23 14:44, Greg Kroah-Hartman wrote:
> On Tue, Dec 12, 2023 at 11:17:21AM +0000, Gavrilov Ilia wrote:
>> Syzkaller reports memory leak issue at gsmld_attach_gsm() in
>> 5.10 stable releases. The reproducer injects the memory allocation
>> errors to tty_register_device(); as a result, tty_kref_get() isn't called
>> after this error, which leads to tty_struct leak.
>> The issue has been fixed by the following patches that can be cleanly
>> applied to the 5.10 branch.
>>
>> Found by InfoTeCS on behalf of Linux Verification Center
>> (linuxtesting.org) with Syzkaller
> 
> Do you actually have any hardware for this protocol running on the
> 5.10.y kernel?  How was this tested?  Why was just this specific set of
> patches picked to be backported?
> 

No, I don't have any hardware for this protocol. I tested this manually 
on virtual machines and using a reproducer (generated by syzkaller).
The first patch fixes the main problem(memory leak). The third patch 
fixes the problem with а null pointer dereference. I added this patch 
because it has a "fixes" tag that references to the first patch. The 
third patch can't be applied cleanly without the second patch.

> thanks,
> 
> greg k-h