I got it to build. I'll try to find the breaking commit and report.
TV adapter drivers missing from 11.0.4?
-
Rataplan626 -
January 16, 2024 at 10:25 AM -
Thread is Resolved
-
-
This is what came out:
Code
Display More5d0fe30be4e28abe373bf951416f29afb0651e01 is the first bad commit commit 5d0fe30be4e28abe373bf951416f29afb0651e01 Author: Christoph Hellwig <[email protected]> Date: Tue Aug 1 19:35:44 2023 +0200 modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules 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. Fixes: 262e6ae7081d ("modules: inherit TAINT_PROPRIETARY_MODULE") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> kernel/module/main.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
It talks about NVidia, which doesn't have much to do with this I suppose, but it seemingly affects these TV tuners in TVHeadend.
So... now what
-
Is this patch in the kernel source? https://patchwork.kernel.org/project/linux-…foundation.org/
-
I'm really sorry for my compile noobness, but how do I check?
-
but it seemingly affects these TV tuners in TVHeadend
This was fixed by https://github.com/torvalds/linux…4c05c89f46e41d1
-
Sounds good. So when Raspbian incorporates that into their builds, it will one day 'automatically' end up in LE? Is that how things work? Now I have this build system up and running, can I build an 11.0.6 with this patch incorporated?
-
DVB was broken in 6.1.52 and fixed in 6.1.53. LE 11.0.4 use kernel 6.1.68. So this must be something else.
-
I'm really sorry for my compile noobness, but how do I check?
"git show <hash>" should output the patch content if the upstream kernel hashes have been merged correctly into the downstream Raspberry Pi kernel source that we use with RPi images. If they haven't, that will error and you'll have to search (grep) the commit log to find the commit message and confirm the patch is present.
-
Sorry for the late reply, life hit me hard the last couple of weeks. Getting everything back on track now. This weekend I updated to LE12 on a test SD-card, and it still doesn't work. My build-vm is still on 11 though.
git seems to report that patch is present:
Code
Display Moregit show 5d0fe30be4e28abe373bf951416f29afb0651e01 commit 5d0fe30be4e28abe373bf951416f29afb0651e01 (refs/bisect/bad) Author: Christoph Hellwig <[email protected]> Date: Tue Aug 1 19:35:44 2023 +0200 modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules 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. Fixes: 262e6ae7081d ("modules: inherit TAINT_PROPRIETARY_MODULE") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> diff --git a/kernel/module/main.c b/kernel/module/main.c index 7a6f43d2b775..7a376e26de85 100644 --- a/kernel/module/main.c
and some more after that.
So that patch seems to be incorporated.
-
Anyone? How could I continue from here reporting this bug in the kernel? Would it make sense to try a linux box with a newer kernel and see if it works again? Would I be right to assume if that would work, at some point it would work in LE again when they incorporate newer kernels as well?
-
Yeah I'm hitting this. Mighty irritating. Previously I just loaded an old kernel and be done with it, but it's getting harder and harder to stay on such an older kernel.
I'll try to debug somewhere this month. Haven't done a bisect with kernels yet, that'll be interesting. Anyone got an idea how to bisect this efficiently? VM in a VM with USB passthrough? It would really suck to do this manually.
-
I did it on the real hardware but a vm could work I guess. It didn't even take as much time as I expected, but yes it's a bit of a hassle. I did it twice and came on the same patch both times. I wonder if you end up on the same erroneous patch.
-
Dear lord, the bisecting is rather arcane, only to be made worse by debian/ubuntu's irritating default to just friggin' rebuild the WHOLE thing after each iteration.
But, you came up with the 'modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules' one right?
That's a red herring I guess. The problem is definitely with this one:
c30411266fd67ea3c02a05c157231654d5a3bdc9 media: anysee: fix null-ptr-deref in anysee_master_xferDiff
Display Morediff --git a/drivers/media/usb/dvb-usb-v2/anysee.c b/drivers/media/usb/dvb-usb-v2/anysee.c index fb6d99dea3..08fdb9e5e3 100644 --- a/drivers/media/usb/dvb-usb-v2/anysee.c +++ b/drivers/media/usb/dvb-usb-v2/anysee.c @@ -202,7 +202,7 @@ static int anysee_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msg, while (i < num) { if (num > i + 1 && (msg[i+1].flags & I2C_M_RD)) { - if (msg[i].len > 2 || msg[i+1].len > 60) { + if (msg[i].len != 2 || msg[i + 1].len > 60) { ret = -EOPNOTSUPP; break; }
I'm no kernel developer, but the commit message states this is to fix a nullptr deref of msg[i].buf. If that's the intended behaviour, then why not check explicitly for msg.buff == NULL?
Well, I reverted the patch and introduced my proposed NULL check, so:Diff
Display Morediff --git a/drivers/media/usb/dvb-usb-v2/anysee.c b/drivers/media/usb/dvb-usb-v2/anysee.c index 08fdb9e5e3..9d72b7924c 100644 --- a/drivers/media/usb/dvb-usb-v2/anysee.c +++ b/drivers/media/usb/dvb-usb-v2/anysee.c @@ -202,7 +202,7 @@ static int anysee_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msg, while (i < num) { if (num > i + 1 && (msg[i+1].flags & I2C_M_RD)) { - if (msg[i].len != 2 || msg[i + 1].len > 60) { + if (msg[i].buf == NULL || msg[i].len > 2 || msg[i + 1].len > 60) { ret = -EOPNOTSUPP; break; }
Lo and behold, it works again. Not sure if my NULL check is equivalently safe as the author of the patch intended. I'll try to get this upstreamed.
Maybe this is a Anysee e30 *combo* edge case we're running into? Maybe the msg.len is actually 2 for other variants of the E30 and 1 for the combo?
No idea how the device and the driver work with regards to initialization. Come to think, my only other linux kernel contribution was 15 years ago or something, I had to supply a patch for the E30C to get it working after suspend to ram. -
okaaaay, well that was a waste of time, fix is already in: https://lore.kernel.org/linux-media/b3…[email protected]/
> media: anysee: accept read buffers of length 1 in anysee_master_xfer -
I was just typing a reply when your last update popped up. Weird how I came up with another patch that borked it twice. Still, for the time being, how would I build the kernel for now without the borked patch, or with yout update? I can find my way in Linux, but I'm not into kernel building apart from al the builds I made during this bisecting. By the way, on my laptop the initial LE build took like 45 minutes, but with the changed kernel only a few minutes.
-
Code
git remote add chewitt https://github.com/chewitt/LibreELEC.tv.git git fetch chewitt dvb-fix git checkout -b dvb-fix git reset --hard chewitt/dvb-fix PROJECT=RPi DEVICE=RPi4 ARCH=aarch64 make release
I pushed the required kernel change to https://github.com/chewitt/LibreELEC.tv/commits/dvb-fix so the above ^ commands will fetch the commits from the dvb-fix branch in my repo, checkout a new branch, reset the state of that branch to match my dvb-fix branch, and then build an LE12 nightly image.
If you can confirm it's fixed with that patch I'll push the change to LE12/master branches.
-
I can't get it to build, during the build it can't find that specific version of fakeroot:
--2024-06-10 17:29:26-- http://sources.libreelec.tv/mirror/fakeroo…oot-1.34.tar.gz
Resolving sources.libreelec.tv (sources.libreelec.tv)... 65.109.172.87
Connecting to sources.libreelec.tv (sources.libreelec.tv)|65.109.172.87|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2024-06-10 17:29:26 ERROR 404: Not Found.Doesn't matter if I take 12.0.0 or the latest nightly.
I'm currently finding out how I can add sources to the building mechanism, as I found multiple repositories with that version in.
-
Option #1 is to change the source URL that we download from in the package.mk.
Option #2 is to manually download and place in your sources folder, then create the filename.sha256 checksum and filename.url for the package and the buildsystem will process them as if it had downloaded them.
Option #3 is to ask nicely and someone on staff can usually upload it to our mirror (which I've done now).
-