On 22/12/2022 15:21, Mirsad Goran Todorovac wrote:
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.
Sorry, maybe I am confused, but from where does 4.16 come?
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.
Yes it is the same diff so no need to re-test really.
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?
Indeed. Attackers imagination can be pretty impressive so I'd rather
assume it is exploitable than that it isn't. Luckily it is "just" a
memory leak rather and information leak or worse. Hopefully we can merge
the fix soon, as soon as a willing reviewer is found.
Regards,
Tvrtko
