Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d8d62c8a-32e0-9975-5ed5-b832bb8df549@alu.unizg.hr>
Date:   Thu, 22 Dec 2022 16:21:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
From:   Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Subject: Re: LOOKS GOOD: Possible regression in drm/i915 driver: memleak
To:     Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
        srinivas pandruvada <srinivas.pandruvada@linux.intel.com>,
        LKML <linux-kernel@vger.kernel.org>, jani.nikula@linux.intel.com,
        joonas.lahtinen@linux.intel.com,
        Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc:     Thorsten Leemhuis <regressions@leemhuis.info>,
        intel-gfx@lists.freedesktop.org
References: <f849cc70-b21f-6476-ba26-08989d1243c2@alu.unizg.hr>
 <05424a5351a847786377a548dba0759917d8046c.camel@linux.intel.com>
 <15ef1bb9-7312-5d98-8bf0-0af1a37cfd2a@linux.intel.com>
 <619bdecc-cf87-60a4-f50d-836f4c073ea7@alu.unizg.hr>
 <8e080674-36ab-9260-046e-f4e3c931a3b9@alu.unizg.hr>
 <96661293-32d7-0bb4-fb0e-28086eaaecc3@linux.intel.com>
Content-Language: en-US, hr, en-GB, de-DE
In-Reply-To: <96661293-32d7-0bb4-fb0e-28086eaaecc3@linux.intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 12/22/2022 09:04, Tvrtko Ursulin wrote:

>
> On 22/12/2022 00:12, Mirsad Goran Todorovac wrote:
>> On 20. 12. 2022. 20:34, Mirsad Todorovac wrote:
>>
>> As I hear no reply from Tvrtko, and there is already 1d5h uptime with 
>> no leaks (but
>> the kworker with memstick_check nag I couldn't bisect on the only box 
>> that reproduced it,
>> because something in hw was not supported in pre 4.16 kernels on the 
>> Lenovo V530S-07ICB.
>> Or I am doing something wrong.)
>>
>> However, now I can find the memstick maintainers thanks to Tvrtko's 
>> hint.
>>
>> If you no longer require my service, I would close this on my behalf.
>>
>> I hope I did not cause too much trouble. The knowledgeable knew that 
>> this was not a security
>> risk, but only a bug. (30 leaks of 64 bytes each were hardly to 
>> exhaust memory in any realistic
>> time.)
>>
>> However, having some experience with software development, I always 
>> preferred bugs reported
>> and fixed rather than concealed and lying in wait (or worse, found 
>> first by a motivated
>> adversary.) Forgive me this rant, I do not live from writing kernel 
>> drivers, this is just a
>> pet project as of time being ...
Hi,
> It is not forgotten - I was trying to reach out to the original author 
> of the fixlet which worked for you. If that fails I will take it up on 
> myself, but need to set aside some time to get into the exact problem 
> space before I can vouch for the fix and send it on my own.
That's good news. Possibly with some assistance I could bisect on pre 
4.16 kernels with the additional drivers.
> In the meantime definitely thanks a lot for testing this quickly and 
> reporting back!
Not at all, I considered it a privilege to assist your team.
> What will happen next is, that when either the original author or 
> myself are ready to send out the fix as a proper patch, you will be 
> copied on it via the "Reported-by" and possibly "Tested-by" tags. 
> Latter is if the patch remains identical. If it changes we might 
> kindly ask you to re-test if possible.

I've seen the published patch and it seems like the same two lines 
change (-1/+1).
In case of a change, I will attempt to test with the same config, setup 
and running programs.

I may need to correct myself in regard as to security aspect of this 
patch as addressed in 786555987207.

QUOTE:

     Currently we create a new mmap_offset for every call to
     mmap_offset_ioctl. This exposes ourselves to an abusive client that may
     simply create new mmap_offsets ad infinitum, which will exhaust 
physical
     memory and the virtual address space. In addition to the exhaustion, a
     very long linear list of mmap_offsets causes other clients using the
     object to incur long list walks -- these long lists can also be
     generated by simply having many clients generate their own mmap_offset.

It is unobvious whether the bug that caused chrome to trigger 30 
memleaks could be exploited by an
abusive script to exhaust larger parts of kernel memory and possibly 
crash the kernel?

Thanks,
Mirsad

-- 
Mirsad Goran Todorovac
Sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
--
System engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
tel. +385 (0)1 3711 451
mob. +385 91 57 88 355