The 6.17 kernel has been released

[Posted September 28, 2025 by corbet]

Linus Torvalds has released the 6.17 kernel. He notes that the shortlog for the changes since -rc7 are pretty tame:

It's not exciting, which is all good. I think the biggest patch in there is some locking fixes for some bluetooth races that could cause use-after-free situations. Whee - that's about as exciting as it gets.
Other than that, there' the usual driver fixlets (GPU and networking dominate as usual, but "dominate" is still pretty small), there's some minor random other driver updates, some filesystem noise, and core kernel and mm.
And some selftest updates.

Significant features in this release include better control over x86 Spectre mitigations, live patching support on 64-bit Arm platforms, a number of pidfd improvements, the removal of special support for uniprocessor systems, initial support for proxy execution, experimental large-folio support in the Btrfs filesystem, the file_getattr() and file_setattr() system calls, and support for the DualPI2 congestion-control protocol.

See the LWN merge-window summaries (part 1, part 2) for more information. In addition, KernelNewbies has a look at the changes that went into 6.17.

Not a bot

Posted Sep 29, 2025 9:22 UTC (Mon) by alfille (subscriber, #1631) [Link] (5 responses)

The link to DualPI2 is impossible because of the Bot test. At least for me. I understand the desire, but it makes browsing (and learning) difficult.

Is theres policy on links?

Not a bot

Posted Sep 29, 2025 9:32 UTC (Mon) by knewt (subscriber, #32124) [Link]

It appears to be a web.git.kernel.org issue, as when trying to follow the link myself just now I found what appeared to be an infinite loop. It did eventually pass me through, though it felt like that would never happen. I tried a couple more times to confirm, and got the same result.

Then found this: https://github.com/TecharoHQ/anubis/issues/1128 # Any link to Linux kernel Git repository at web.git.kernel.org causes infnite loop

So it seems to have been an issue for at least a couple of weeks now. I will note that it's the only Anubis-protected site that I've seen an issue with, so as noted in the issue it seems to be a site-specific issue. Not that this stops it being frustrating!

Not a bot

Posted Sep 29, 2025 9:33 UTC (Mon) by corbet (editor, #1) [Link] (3 responses)

Any link policy that disallows linking into kernel.org would clearly pose certain difficulties here ... in any case, the link works for me, but I know that the bot protections there have occasionally had problems. I don't doubt that they will be worked out.

Not a bot

Posted Sep 29, 2025 10:19 UTC (Mon) by johill (subscriber, #25196) [Link] (2 responses)

As far as I've heard, Konstantin is phasing out web.git.kernel.org in favour of just git.kernel.org. I've seen a (near) infinite redirect on web.git.kernel.org from anubis, but the almost-same URLs work fine with just git.kernel.org instead. I'm not sure why the redirect is causing anubis to get mixed up, but it's easy to just drop the "web." part.

Not a bot

Posted Sep 29, 2025 14:27 UTC (Mon) by jake (editor, #205) [Link] (1 responses)

> I'm not sure why the redirect is causing anubis to get mixed up, but it's easy to just drop the "web." part.

When I checked those links last night, they worked fine, but they aren't now for me either, so I removed 'web.' as you suggest.

thanks,

jake

Not a bot

Posted Sep 29, 2025 15:01 UTC (Mon) by knewt (subscriber, #32124) [Link]

Possibly you had a non-expired cookie from Anubis for the "web." domain, so not triggering the challenge and bypassing the issue as a result?

legacy iptables broken

Posted Sep 29, 2025 18:52 UTC (Mon) by alanjwylie (subscriber, #4794) [Link] (4 responses)

I'm still using legacy iptables.

During a "make oldconfig", CONFIG_NETFILTER_XTABLES_LEGACY defaulted to "n". On rebooting into 6.17.0 iptables wouldn't work. Even rebuilding with the option set to "y", things still weren't the same as with 6.16.9.

legacy iptables broken

Posted Sep 29, 2025 19:07 UTC (Mon) by dskoll (subscriber, #1630) [Link] (3 responses)

Ooh, thanks for the heads-up. I guess I'd better research the new way of doing things (nftables?) sigh

legacy iptables broken

Posted Sep 29, 2025 19:09 UTC (Mon) by dskoll (subscriber, #1630) [Link] (2 responses)

Replying to self... looks like iptables-nft should make the transition pretty easy. Does that not work for you?

legacy iptables broken

Posted Sep 29, 2025 20:05 UTC (Mon) by alanjwylie (subscriber, #4794) [Link] (1 responses)

> Replying to self... looks like iptables-nft should make the transition pretty easy. Does that not work for you?

I run Gentoo, which allows selection of nft

# eselect iptables list
Available iptables symlink targets:
[1] xtables-legacy-multi *
[2] xtables-nft-multi
#

I did try setting it to [2] at one point, but I'm not sure whether that was before or after I'd identified CONFIG_NETFILTER_XTABLES_LEGACY as possibly being implicated and rebuilt the kernel. Anyway, it didn't
help at that time. There may be other config options I need to set.

It's getting late here, I'm out tomorrow, a build of the kernel on my aging AMD FX-4300 with spinning rust takes ages.

I'll try again tomorrow evening.

legacy iptables broken

Posted Sep 30, 2025 6:08 UTC (Tue) by alanjwylie (subscriber, #4794) [Link]

I've just had a helpful email from Brad Spengler. Setting CONFIG_NETFILTER_XTABLES_LEGACY to y won't help in a config where it's previously defaulted to no, there are other options that will have been set to no at the same time. Starting afresh with a good config and setting it to y in "make oldconfig" should work.