| 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
| ||
|
Message-ID: <20230907221737.07f12f38@mir>
Date: Thu, 7 Sep 2023 22:17:37 +0200
From: Stefan Lippers-Hollmann <s.l-h@....de>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: stable@...r.kernel.org, patches@...ts.linux.dev,
Christoph Hellwig <hch@....de>,
Luis Chamberlain <mcgrof@...nel.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6.5 11/34] modules: only allow symbol_get of
EXPORT_SYMBOL_GPL modules
Hi
On 2023-09-07, Greg Kroah-Hartman wrote:
> On Thu, Sep 07, 2023 at 08:41:35AM +0200, Stefan Lippers-Hollmann wrote:
> > On 2023-09-04, Greg Kroah-Hartman wrote:
> > > 6.5-stable review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Christoph Hellwig <hch@....de>
> > >
> > > commit 9011e49d54dcc7653ebb8a1e05b5badb5ecfa9f9 upstream.
> > >
> > > It has recently come to my attention that nvidia is circumventing the
> > > protection added in 262e6ae7081d ("modules: inherit
> > > TAINT_PROPRIETARY_MODULE") by importing exports from their proprietary
> > > modules into an allegedly GPL licensed module and then rexporting them.
> > >
> > > Given that symbol_get was only ever intended for tightly cooperating
> > > modules using very internal symbols it is logical to restrict it to
> > > being used on EXPORT_SYMBOL_GPL and prevent nvidia from costly DMCA
> > > Circumvention of Access Controls law suites.
> > >
> > > All symbols except for four used through symbol_get were already exported
> > > as EXPORT_SYMBOL_GPL, and the remaining four ones were switched over in
> > > the preparation patches.
> >
> > This patch, as part of v6.5.2, breaks the in-kernel ds3000 module
> > (for a TeVii s480 v2 DVB-S2 card, which is a PCIe card attaching two
> > onboard TeVii s660 cards via an onboard USB2 controller (MCS9990),
> > https://www.linuxtv.org/wiki/index.php/TeVii_S480) from loading.
>
> This is also broken in Linus's tree, right?
Yes, HEAD as of 6.5.0-12145-g4a0fc73da97e is affected just as well.
> > [ 2.896589] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
> > [ 2.901085] failing symbol_get of non-GPLONLY symbol ds3000_attach.
> > [ 2.901089] DVB: Unable to find symbol ds3000_attach()
>
> This is odd, where is that call coming from? I don't see any call to
> symbol_get in the dvb code, where is this happening?
>
> Anyway, does the patch below fix this?
That change alone only moves the issue down to ts2020_attach().
$ dmesg | grep -i -e dvb -e gpl -e symbol
[ 1.464876] usb 3-1: Product: DVBS2BOX
[ 1.482143] usb 5-1: Product: DVBS2BOX
[ 3.692647] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware
[ 3.692951] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
[ 3.860571] dvb-usb: found a 'TeVii S660 USB' in warm state.
[ 3.860615] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 3.860944] dvbdev: DVB: registering new adapter (TeVii S660 USB)
[ 4.097144] dvb-usb: MAC address: 00:18:XX:XX:XX:XX
[ 4.097272] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[ 4.111792] failing symbol_get of non-GPLONLY symbol ts2020_attach.
[ 4.111795] DVB: Unable to find symbol ts2020_attach()
[ 4.112759] usb 3-1: DVB: registering adapter 0 frontend 0 (Montage Technology DS3000)...
[ 4.112764] dvbdev: dvb_create_media_entity: media entity 'Montage Technology DS3000' registered.
[ 4.138938] dvb-usb: schedule remote query interval to 150 msecs.
[ 4.138942] dvb-usb: TeVii S660 USB successfully initialized and connected.
[ 4.138988] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware
[ 4.139016] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
[ 4.292614] dvb-usb: found a 'TeVii S660 USB' in warm state.
[ 4.292679] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 4.293075] dvbdev: DVB: registering new adapter (TeVii S660 USB)
[ 4.538876] dvb-usb: MAC address: 00:18:XX:XX:XX:XX
[ 4.539113] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[ 4.543738] failing symbol_get of non-GPLONLY symbol ts2020_attach.
[ 4.546349] failing symbol_get of non-GPLONLY symbol ts2020_attach.
[ 4.546354] DVB: Unable to find symbol ts2020_attach()
[ 4.548643] usb 5-1: DVB: registering adapter 1 frontend 0 (Montage Technology DS3000)...
[ 4.548650] dvbdev: dvb_create_media_entity: media entity 'Montage Technology DS3000' registered.
[ 4.549970] dvb-usb: schedule remote query interval to 150 msecs.
[ 4.549973] dvb-usb: TeVii S660 USB successfully initialized and connected.
[ 7.830408] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)...
[ 8.367600] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)...
Extending this to approach to ts2020_attach() does fix the problem
for me. Searching the web for "failing symbol_get of non-GPLONLY
symbol" suggests that there might be further instances within the
DVB subsystem https://syzkaller.appspot.com/x/log.txt?x=11faa1eda80000
(this was merely gathered by a passive web search, I have no contact
to the poster or any further information about it).
[ now fully functional with EXPORT_SYMBOL_GPL(ds3000_attach) and
EXPORT_SYMBOL_GPL(ts2020_attach) ]
$ dmesg | grep -i -e dvb -e gpl -e symbol -e taint
[ 1.499064] usb 3-1: Product: DVBS2BOX
[ 1.505760] usb 4-1: Product: DVBS2BOX
[ 3.915802] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware
[ 3.917134] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
[ 4.084566] dvb-usb: found a 'TeVii S660 USB' in warm state.
[ 4.084602] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 4.084984] dvbdev: DVB: registering new adapter (TeVii S660 USB)
[ 4.320740] dvb-usb: MAC address: 00:18:XX:XX:XX:XX
[ 4.320871] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[ 4.390349] usb 3-1: DVB: registering adapter 0 frontend 0 (Montage Technology DS3000)...
[ 4.390356] dvbdev: dvb_create_media_entity: media entity 'Montage Technology DS3000' registered.
[ 4.416869] dvb-usb: schedule remote query interval to 150 msecs.
[ 4.416872] dvb-usb: TeVii S660 USB successfully initialized and connected.
[ 4.416905] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware
[ 4.416927] dvb-usb: downloading firmware from file 'dvb-usb-s660.fw'
[ 4.572611] dvb-usb: found a 'TeVii S660 USB' in warm state.
[ 4.572679] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 4.573066] dvbdev: DVB: registering new adapter (TeVii S660 USB)
[ 4.821631] dvb-usb: MAC address: 00:18:XX:XX:XX:XX
[ 4.821757] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[ 4.884845] usb 4-1: DVB: registering adapter 1 frontend 0 (Montage Technology DS3000)...
[ 4.884856] dvbdev: dvb_create_media_entity: media entity 'Montage Technology DS3000' registered.
[ 4.886511] dvb-usb: schedule remote query interval to 150 msecs.
[ 4.886514] dvb-usb: TeVii S660 USB successfully initialized and connected.
[ 7.312401] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)...
[ 7.918355] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)...
[ 7.919675] ds3000_firmware_ondemand: Waiting for firmware upload (dvb-fe-ds3000.fw)...
With these changes, my DVB-S2 and DVB-T2 cards are working:
- https://www.linuxtv.org/wiki/index.php/TeVii_S480
- https://www.linuxtv.org/wiki/index.php/Xbox_One_Digital_TV_Tuner
Thanks a lot
Stefan Lippers-Hollmann
---
--- a/drivers/media/dvb-frontends/ts2020.c
+++ b/drivers/media/dvb-frontends/ts2020.c
@@ -525,7 +525,7 @@ struct dvb_frontend *ts2020_attach(struc
return fe;
}
-EXPORT_SYMBOL(ts2020_attach);
+EXPORT_SYMBOL_GPL(ts2020_attach);
/*
* We implement own regmap locking due to legacy DVB attach which uses frontend
Powered by blists - more mailing lists