Re: [Cocci] Coccinelle rule for CVE-2019-18683
> Analysing each matching case would take a lot of time. How many efforts would you like to invest in adjusting the situation? Will any more development possibilities picked up to reduce the presentation of false positives by the mentioned source code analysis approach considerably? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Coccinelle rule for CVE-2019-18683
On 09.04.2020 22:41, Alexander Popov wrote:
> On 09.04.2020 01:26, Jann Horn wrote:
>> On Thu, Apr 9, 2020 at 12:01 AM Alexander Popov wrote:
>>> CVE-2019-18683 refers to three similar vulnerabilities caused by the same
>>> incorrect approach to locking that is used in
>>> vivid_stop_generating_vid_cap(),
>>> vivid_stop_generating_vid_out(), and sdr_cap_stop_streaming().
>>>
>>> For fixes please see the commit 6dcd5d7a7a29c1e4 (media: vivid: Fix wrong
>>> locking that causes race conditions on streaming stop).
>>>
>>> These three functions are called during streaming stopping with
>>> vivid_dev.mutex
>>> locked. And they all do the same mistake while stopping their kthreads,
>>> which
>>> need to lock this mutex as well. See the example from
>>> vivid_stop_generating_vid_cap():
>>> /* shutdown control thread */
>>> vivid_grab_controls(dev, false);
>>> mutex_unlock(>mutex);
>>> kthread_stop(dev->kthread_vid_cap);
>>> dev->kthread_vid_cap = NULL;
>>> mutex_lock(>mutex);
>>>
>>> But when this mutex is unlocked, another vb2_fop_read() can lock it instead
>>> of
>>> the kthread and manipulate the buffer queue. That causes use-after-free.
>>>
>>> I created a Coccinelle rule that detects
>>> mutex_unlock+kthread_stop+mutex_lock
>>> within one function.
>> [...]
>>> mutex_unlock@unlock_p(E)
>>> ...
>>> kthread_stop@stop_p(...)
>>> ...
>>> mutex_lock@lock_p(E)
>>
>> Is the kthread_stop() really special here? It seems to me like it's
>> pretty much just a normal instance of the "temporarily dropping a
>> lock" pattern - which does tend to go wrong quite often, but can also
>> be correct.
>
> Right, searching without kthread_stop() gives more cases.
>
>> I think it would be interesting though to have a list of places that
>> drop and then re-acquire a mutex/spinlock/... that was not originally
>> acquired in the same block of code (but was instead originally
>> acquired in an outer block, or by a parent function, or something like
>> that). So things like this:
The following rule reported 146 matching cases, which might be interesting.
```
virtual report
virtual context
@race exists@
expression E;
position unlock_p;
position lock_p;
@@
... when != mutex_lock(E)
* mutex_unlock@unlock_p(E)
... when != schedule()
when != schedule_timeout(...)
when != cond_resched()
when != wait_event(...)
when != wait_event_timeout(...)
when != wait_event_interruptible_timeout(...)
when != wait_event_interruptible(...)
when != msleep()
when != msleep_interruptible(...)
* mutex_lock@lock_p(E)
@script:python@
unlock_p << race.unlock_p;
lock_p << race.lock_p;
E << race.E;
@@
coccilib.report.print_report(unlock_p[0], 'see mutex_unlock(' + E + ') here')
coccilib.report.print_report(lock_p[0], 'see mutex_lock(' + E + ') here\n')
```
Analysing each matching case would take a lot of time.
However, I'm focused on searching kernel security issues.
So I will filter out the code that:
- is not enabled in popular kernel configurations,
- doesn't create additional attack surface.
Then I'll take the time to analyse the rest of reported cases.
I'll inform you if I find any bug.
Best regards,
Alexander
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Searching for functions with negative return values as error indication
> Maybe you can just take inspiration from this paper: > > https://pages.lip6.fr/Julia.Lawall/dsn09.pdf I find the information from this document “WYSIWIB: A Declarative Approach to Finding API Protocols and Bugs in Linux Code” also interesting. Did the mentioned tools “Search”, “Instantiate”, “MakeBugReport” and “MultiSearch” evolve any further (besides the Coccinelle software in the meantime)? It seems to be more popular to look for inconsistent error checks together with pointer data types. Can the software situation be improved also around integral data types currently? Will the known limitations of Coccinelle for protocol and bug finding get any more software development attention? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Searching for functions with negative return values as error indication
On Fri, 10 Apr 2020, Markus Elfring wrote: > Hello, > > Several functions for a programming language like C are designed in the way > that values are returned by an integral data type. > Specific value ranges can indicate then a failed function call. > A well-known variant of this design pattern is that negative return values > represent failures (while the other values can be used for succesful data > processing. > Can the semantic patch language help any more to determine the list of > functions which use this style of error reporting in a selected code base? Maybe you can just take inspiration from this paper: https://pages.lip6.fr/Julia.Lawall/dsn09.pdf julia > > Regards, > Markus > ___ > Cocci mailing list > Cocci@systeme.lip6.fr > https://systeme.lip6.fr/mailman/listinfo/cocci > ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] Searching for functions with negative return values as error indication
Hello, Several functions for a programming language like C are designed in the way that values are returned by an integral data type. Specific value ranges can indicate then a failed function call. A well-known variant of this design pattern is that negative return values represent failures (while the other values can be used for succesful data processing. Can the semantic patch language help any more to determine the list of functions which use this style of error reporting in a selected code base? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Coccinelle rule for CVE-2019-18683
>> * The source code search pattern can be too generic. >> How do you think about to consider additional constraints >> for safer data control flow analysis? > > Could you please elaborate on that? Julia Lawall chose to mention the design possibility “put when != mutex_lock(E) after the ...”. https://systeme.lip6.fr/pipermail/cocci/2020-April/007107.html https://lore.kernel.org/cocci/alpine.DEB.2.21.2004091248190.2403@hadrien/ > I used 'exists' keyword to find at least one branch that has > mutex_unlock+kthread_stop+mutex_lock chain. Are you informed about development challenges for data flow analysis (or even escape analysis according to computer science)? How many experiences can be reused from other known approaches? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
