Thorsten Leemhuis (acct. 1/4)

In case #Linux 7.2, v7.1.9+, or v6.18.45+ broke Bluetooth for you, then it's likely the following known problem in case you have a Realtek RTL8761B/BU BT chip:

• https://lore.kernel.org/all/20260822141115.58815-1-kserwus@gmail.com/
• https://lore.kernel.org/all/20260823102959.100368-1-kserwus@gmail.com/
• https://lore.kernel.org/all/20260824053227.317496-1-junjie.cao@intel.com/
• https://bugzilla.redhat.com/show_bug.cgi?id=2521504

#LinuxKernel #kernel

Quick reminder in light of the recent #LinuxKernel vulnerabilities:

In case you want to protect yourself against vulnerabilities in #Linux #Kernel modules you don't need, disable module loading completely by running:

echo 1 | sudo tee /proc/sys/kernel/modules_disabled

Of course you want to load all modules you need before running that command, as otherwise you will have to reboot to load them. 😄

More details on this:

* https://dfir.ch/posts/today_i_learned_lkm_kernel.modules_disabled/
* https://linux-audit.com/kernel/increase-kernel-integrity-with-disabled-linux-kernel-modules-loading/
* https://www.heise.de/select/ct/2020/1/1577462303523965 [German]

"[…] The "#CopyFail" vulnerability presented a unique challenge for us. Despite our practice of deploying #Linux patch updates every two weeks, we remained vulnerable because a month-old mainline fix had yet to be backported to our primary #kernel line. Despite that, we were still able to roll out patched kernels within hours of the backport's release. In the interim, #bpf-lsm provided a surgical, no-reboot mitigation that secured our fleet. […]"

https://blog.cloudflare.com/copy-fail-linux-vulnerability-mitigation/

#LinuxKernel

Reminder[1]: Now is the best[2] time to test the #kernel to prevent #LinuxKernel regressions from hitting #ArchLinux, #Fedora Linux, or #openSUSE #Tumbleweed.

That's because the first pre-release (aka "-rc1") of #Linux 7.1 is out – which leaves plenty of time to find, report, debug, and fix any problems that those distros otherwise will encounter when they switch to 7.1.y in about eight to ten weeks. And testing is not even hard, as easy-to-install packages with pre-built mainline kernels exist for all three distros[3].

Testing in one or two weeks when -rc2 or -rc3 are out is good, too. But you really want to test by 7.1-rc6 (five weeks from now): By then, Linus wants all regressions introduced and reported early in the 7.1 cycle to be fixed. Things are thus expected to work by then – but if not, there is still enough time to test, debug, and fix most regressions.

Reporting any later is often too late to fix regressions before those distros switch to the 7.1.y series -- which will happen within one or two weeks (in the case of Arch and Tumbleweed) or three to four (Fedora) after 7.1 is released, as 7.0.y likely becomes EOL about two weeks after 7.1 is out. This is why they'll switch then, even if regressions are known.

[1] I published similar posts in the past

[2] "best"/"good" as in "best tradeoff between risk and impact"

[3] Arch: https://aur.archlinux.org/packages/linux-mainline
Fedora: https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/mainline-wo-mergew/
Tumbleweed: https://download.opensuse.org/repositories/Kernel:/vanilla/

From David Malcolm, who among others mentioned:

* GCC error messages have a hierarchical structure to them. In GCC 15, I added an experimental option that shows this structure as a collection of nested bullet points. In GCC 16, this behavior is now the default.

* GCC 16 includes several improvements to the generated SARIF output.

* In GCC 15, I added -fdiagnostics-add-output= to allow for multiple kinds of diagnostic output simultaneously. Plain text output has limitations, so GCC 16 includes a new experimental-html option.

* Static analyzer improvements

https://developers.redhat.com/articles/2026/04/28/gcc-16-improved-error-messages-sarif-output

#gcc #gcc16

Censorship, censorship everywhere, even on kernel.org ! 😮

[For the record: I assume that's a bug in the dark mode of cgit or something like that]

#Linux 7.1-rc3, 7.0.6 and 6.18.29 are out with a fix for the second half of the #DirtyFrag vulnerability:

* https://git.kernel.org/torvalds/c/aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-7.0.y&id=d45179f8795222ce858770dc619abe51f9d24411
* https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=3eae0f4f9f7206a4801efa5e0235c25bbd5a412c

Thing is: it seems that the fix might have some problems, so a fix for the fix is in the works:

* https://lore.kernel.org/all/20260510084520.476745b5@kernel.org/t/#u
* https://lore.kernel.org/all/agDTmXM2wXnJflYc@v4bel/

#LinuxKernel #kernel

RE: @kernellogger@hachyderm.io

A bunch of old networking infrastructure and drivers after a short discussion phase were now removed for #Linux 7.1. Among them:
* ISDN subsystem and Bluetooth CMTP
* ax25 and amateur radio (hamradio)
* CAIF NETWORK LAYER
* used ATM protocols and legacy ATM device drivers
* several drivers, among them the one for 3com 3c509 chips

For details see: https://git.kernel.org/torvalds/c/64edfa65062dc4509ba75978116b2f6d392346f5

In case you actually use anything in production (see the post below), speak up, as then the removal might be reverted, as Linus clarified in https://lore.kernel.org/all/CAHk-%3DwimzLyMALBZmQUDGs%3DX0uJhnLhpsQJ1c77%3DBMwhx4GT4A@mail.gmail.com/ – to quote:

"I think we can easily resurrect individual drivers if there are actual users."

#LinuxKernel #kernel

RE: @lwn@fedi.lwn.net

The patch to fix the second half of #DirtyFrag is at its third iteration now: https://lore.kernel.org/all/af2kdW2F1gJ9U-Gg@v4bel/

#LinuxKernel #kernel #Linux

Quick reminder wrt removing features or drivers from the #Linux #kernel, like currently considered in the networking subsystem and a few other areas[1]:

The "no regressions" rule still applies – so nothing people still use should be removed (or the removal should be reverted in case it turns out people still use it).

This is why the network drivers 3c59x and xirc2ps, MVME147 that were on the chopping board will remain[2].

But there are a few caveats, some of them:

* "people still use" means "in production with recent kernels" – public or private museums can use old kernel versions.
* You have to make your case against the removal (and might have to help testing going forward) – which is what a few people did successfully for the drivers mentioned above[3].
* Timing is important. It's best to speak up before something is removed. Chances that a removal is reverted are likely good if you speak up in the mainline cycle where the removal was performed. It might work in the following cycle, too (e.g. in the 9 weeks after after a new mainline release where something was removed is out). But if you speak up later, you are likely too late -- which is why you want to use the latest mainline and not jump from one longterm release to the next once a year, as then it most likely is too late when you notice a removal.
* Exceptions from the "no regressions" rule made, for example in case something is seriously broken, a huge security risk/maintenance burden, and basically unfixable at the same time; but these are rare and individual judgement calls, so it is best to not worry about.

[1] https://lwn.net/Articles/1068928/
[2] https://lore.kernel.org/all/20260422-v7-0-0-net-next-driver-removal-v1-v2-0-08a5b59784d5@lunn.ch/ –
[3] https://lore.kernel.org/all/41d9fe43-9aa5-49b4-89cd-9aa13e4e4ea9@lunn.ch/, https://lore.kernel.org/all/408d1987-6ecb-4d3b-afed-8e202c8ff21d@lunn.ch/, and https://lore.kernel.org/all/f902909f-7eb9-4b7a-bb01-82f680cfe695@lunn.ch/

#LinuxKernel

#Linux 7.1-rc2 is out: https://lore.kernel.org/lkml/CAHk-=wjcma=quWe1SsiHkETc6zmRG6HVLcSVchGjAMtn=iimZA@mail.gmail.com/

""I bring you tidings of another regular rc release - 7.1-rc2 is out, and looks fairly normal.

[…]

It's not small, and while it's a bit early to say for sure, I do suspect we're seeing the same continued pattern of more patches than usual - probably due to AI tooling - that we saw in 7.0.

Let's keep testing,

Linus""

#kernel #LinuxKernel

Updated my #Linux #kernel stats document now that #LinuxKernel 7.1 is out: https://docs.google.com/spreadsheets/d/1_yH7lFmZxAoSWrtsd8tGu3befG4zIcMnytB1ml4pQQM/edit?usp=sharing

One thing stood out: the number of commits during the merge window went up for the past two releases, like due to the AI effect.

Will be interesting to see if they will go down again soon after Linus pushed back in the last -rc5 release announcement: https://lore.kernel.org/lkml/CAHk-=wjt1NiKOdyAMz_DT7NmZ++SizPOhRSi492ukdTnpDzHQw@mail.gmail.com/

To quote a few bits:

""[…] rc5 is pretty big. Quite a bit bigger than rc5's have traditionally been.

I'm not entirely happy about it - […]. These things are "fixes", sure, but at the same time a lot of them are simply so irrelevant that I think they'd be better off in a linux-next tree and get merged during the merge window.

So I think I'll start being a bit more hardnosed about this kind of unnecessary churn this late in the game. We are supposed to look for *regressions*. Non-critical fixes to long-standing issues are simply not appropriate for this late in the release cycle.""

#Linux 7.1-rc1 is out:

""Things look fairly normal, although we do have a few different projects to cull some old hardware support to help minimize maintenance burden: phasing out i486 support (configs deleted, code deletions to follow) and independently starting to remove some really old networking hardware support, and removing some SoC support that never went anywhere.

But we're more than making up for any stale code removal with all the new features and code added, so the diffstat still shows many more lines added than removed.

[...]

Let's start testing and calming this thing down,

Linus""

https://lore.kernel.org/lkml/CAHk-=wh7jmSh6bO5VL31hOC3HdTY0QAV-P1H4XZauwL2x=w35Q@mail.gmail.com/

#Linux 7.1-rc3 is out:

https://lore.kernel.org/lkml/CAHk-=wgCu1Ef9-k6w9BEL78Bu9G_oAgJ65opysqL6n3WW3Zw-g@mail.gmail.com/

Linus writes: ""[…] this [rc] answers the "is 7.1 continuing the larger size pattern that we saw with 7.0?" question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal.""

#LinuxKernel #kernel

In case you encounter stuttering/periodic lockups with #linux 7.0, especially on AMD systems, try this patch:

https://lore.kernel.org/all/177636758252.1323100.5283878386670888513.tip-bot2@tip-bot2/

For some reports about the issue, see:
* https://lore.kernel.org/all/68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com/
* https://bugzilla.kernel.org/show_bug.cgi?id=221370
* https://bugzilla.kernel.org/show_bug.cgi?id=221367

#kernel #LinuxKernel

[Edit]

You might want to ignore this post!

Seems the tags were an accident and were already removed in Linus' repo (but they might have ended up in your local mirror if you are unlucky; using the "--prune-tags" option of git fetch might be what you want then, but be careful, it might remove tags you care about).

[/edit]

Wondering why there are suddenly git tags for every downstream merge Linus performs for #Linux 7.2 (which will lead to a lot of tag noise I guess).

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/refs/

#kernel #LinuxKernel

@Aissen@social.treehouse.systems and on general purpose systems use at least the latest longterm kernel, as explained by Greg here:

http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/

They also got the fix (a664bf3d603dc3 ("crypto: algif_aead - Revert to operating out-of-place")) earlier:

• v7.0-rc7 (2026-04-06 00:26:23),
• v6.19.12 (2026-04-11 14:29:58),
• v6.18.22 (2026-04-11 14:26:52),
• v6.12.85 (2026-04-30 11:14:47),
• v6.6.137 (2026-04-30 11:17:22),
• v6.1.170 (2026-04-30 11:19:11),
• v5.15.204 (2026-04-30 11:24:38),
• v5.10.254 (2026-04-30 11:25:29)]

@stefanct yes and no. 😆

• No, as for most users there is no risk, as they run Linux on hardware that was made and sold in say the last ten years or so -- and it would be extremely unusual is someone would suggest removing support for that

• Yes, if you run something older than testing all mainline releases might be wise -- but well, you get what you pay for, so helping here a bit is kinda fair I'd say and a good way to say thx for the work others do.

*But: what I said earlier about removal is true for fixes that accidentally cause a regression for somebody else -- and if you only report that regression after say a year that change maybe can't be reverted, as that would cause a regression for others. This is a reason why you might want to regularly run latest mainline -- but the risk that this happens is rare.

And: Most people should use the latest stable kernels anway: http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/