On 18/06/2021 11:29, Greg Kroah-Hartman wrote: > On Fri, Jun 18, 2021 at 11:22:37AM +0200, Krzysztof Kozlowski wrote: >> On 18/06/2021 11:19, Greg Kroah-Hartman wrote: >>> On Fri, Jun 18, 2021 at 10:57:23AM +0200, Krzysztof Kozlowski wrote: >>>> On 10/05/2021 12:18, Greg Kroah-Hartman wrote: >>>>> From: Christoph Hellwig <hch@xxxxxx> >>>>> >>>>> commit 262e6ae7081df304fc625cf368d5c2cbba2bb991 upstream. >>>>> >>>>> If a TAINT_PROPRIETARY_MODULE exports symbol, inherit the taint flag >>>>> for all modules importing these symbols, and don't allow loading >>>>> symbols from TAINT_PROPRIETARY_MODULE modules if the module previously >>>>> imported gplonly symbols. Add a anti-circumvention devices so people >>>>> don't accidentally get themselves into trouble this way. >>>>> >>>>> Comment from Greg: >>>>> "Ah, the proven-to-be-illegal "GPL Condom" defense :)" >>>> >>>> Patch got in to stable, so my comments are quite late, but can someone >>>> explain me - how this is a stable material? What specific, real bug that >>>> bothers people, is being fixed here? Or maybe it fixes serious issue >>>> reported by a user of distribution kernel? IOW, how does this match >>>> stable kernel rules at all? >>>> >>>> For sure it breaks some out-of-tree modules already present and used by >>>> customers of downstream stable kernels. Therefore I wonder what is the >>>> bug fixed here, so the breakage and annoyance of stable users is justified. >>> >>> It fixes a reported bug in that somehow symbols are being exported to >>> modules that should not have been. This has been in mainline and newer >>> stable releases for quite some time, it should not be a suprise that >>> this was backported further as well. >> >> This is vague. What exactly is the bug? How exporting symbols which >> should not be exported, causes it? Is there OOPs? Some feature does not >> work? > > The bug/issue is that symbols were being incorrectly exported in ways > that they should not have been and were available to users that should > not have been able to use them. That is what this patch series > resolves. I can go into details but they are boring and deal with > closed source monstrosities that feel they are allowed to muck around in > kernel internals at will, which causes a support burden on the kernel > community. Thanks Greg, I would prefer honest "we don't want others to do something we don't like or approve and we can change it" :) > If you object to this, that's fine, you are free to revert them in your > local distro kernel after discussing it with your lawyers to get their > approval to do so. Best regards, Krzysztof
