linux-kernel - Re: [PATCH] KVM: X86: Fix dereference null cpufreq policy

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] [day] [month] [year] [list]

Date:   Mon, 2 Mar 2020 11:23:30 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Wanpeng Li <kernellwp@...il.com>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH] KVM: X86: Fix dereference null cpufreq policy

On 02/03/20 10:14, Viresh Kumar wrote:
>> For the same reason why we support kfree(NULL) and kobject_put(NULL)?
>
> These two helpers are used widely within kernel and many a times the
> resource is taken by one routine and dropped by another, and so
> someone needed to check if it can call the resource-free helper safely
> or not. IMO, that's not the case with cpufreq_cpu_put(). It is used
> mostly by the cpufreq core only and not too often by external
> entities. And even in that case we don't need to call
> cpufreq_cpu_put() from a different routine than the one which called
> cpufreq_cpu_get(). Like in your case. And so there is no need of an
> extra check to be made.
> 
> I don't think we need to support cpufreq_cpu_put(NULL), but if Rafael
> wants it to be supported, I won't object to it.

Actually I think kobject_put is wrong in supporting NULL, because
documentation explicitly says to use container_of and not place kobj as
the first item.  However, there is going to be some place in the kernel
that relies on it, so either removing the check or moving all kobjs to
the beginning of the struct is a windmill fight.  I'll just apply
Wanpeng's patch.

Paolo