Brief items

Local vulnerabilities in Kea DHCP

The SUSE Security Team has published a detailed report about security vulnerabilities it discovered in the Kea DHCP server suite from the Internet Systems Consortium (ISC).

Since SUSE is also going to ship Kea DHCP in its products, we performed a routine review of its code base. Even before checking the network security of Kea, we stumbled over a range of local security issues, among them a local root exploit which is possible in many default installations of Kea on Linux and BSD distributions. [...]

This report is based on Kea release 2.6.1. Any source code references in this report relate to this version. Many systems still ship older releases of Kea, but we believe they are all affected as well by the issues described in this report.

The report details seven security issues including local-privilege-escalation and arbitrary file overwrite vulnerabilities. Security fixes for the vulnerabilities have been published in all of the currently supported release series of Kea: 2.4.2, 2.6.3, and the 2.7.9 development release were all released on May 28. Kea has assigned CVE-2025-32801, CVE-2025-32802, and CVE-2025-32803 to the vulnerabilities. Note that some of the CVEs cover multiple security flaws.

Comments (26 posted)

Security quote of the week

The Take9 campaign tells people that they can stop cyberattacks by taking a pause and making a better decision. What's not said, but certainly implied, is that if they don't take that pause and don't make those better decisions, then they're to blame when the attack occurs.

That's simply not true, and its blame-the-user message is one of the worst mistakes our industry makes. Stop trying to fix the user. It's not the user's fault if they click on a link and it infects their system. It's not their fault if they plug in a strange USB drive or ignore a warning message that they can't understand. It's not even their fault if they get fooled by a look-alike bank website and lose their money. The problem is that we've designed these systems to be so insecure that regular, nontechnical people can't use them with confidence. We're using security awareness campaigns to cover up bad system design. Or, as security researcher Angela Sasse first said in 1999: "Users are not the enemy."

— Bruce Schneier and Arun Vishwanath on Take9

Comments (none posted)

Kernel release status

The 6.16 merge window remains open; it can be expected to close on June 8.

Stable updates: 6.14.9 and 6.12.31 were released on May 29, followed by 6.15.1, 6.14.10, 6.12.32, 6.6.93, 6.1.141, 5.15.185, 5.10.238, and 5.4.294 on June 4.

Comments (none posted)

Quotes of the week

All that aside, yes, I have seen timeouts used in cases where investing a little more thought might have provided a better solution. Then again, the same is true of pretty much all other facilities provided by the Linux kernel. ;-)

— Paul McKenney

Let's have a rule that TLA's [three-letter acronyms] are ok _only_ for things that

• (a) go back at least four decades
• (b) have a basically unambiguous meaning in the industry (let's ignore IBM that made up their own naming)
• (c) when you google them, they give relevant results

So, for example, talking about a "TLB" entry is ok by all three rules, and a TTY is similarly not a bad word.

— Linus Torvalds

Comments (none posted)

Alpine Linux 3.22.0 released

Version 3.22.0 of the Alpine Linux distribution has been released. Notable changes in this release include the removal of the X11 session for KDE Plasma, a switch to systemd-efistub, and experimental support for user services with the OpenRC init system. See the release notes for a detailed list of changes.

Comments (none posted)

Strategy 2028 update (Fedora Community Blog)

Outgoing Fedora Project Leader Matthew Miller has posted an update on Fedora's high-level plan through 2028:

[Fedora] Council members identified potential Initiatives that we believe are important to work on next. We came up with a list of thirteen — which is way more than we can handle at once. We previously set a limit of four Initiatives at a time. We decided to keep to that rule, and are planning to launch four initiatives in the next months

The initiatives are: making Fedora releases block on accessibility issues, experimenting with a "GitOps" workflow for packaging, migrating from Pagure to Forgejo, and "making sure Fedora Linux is ready for people who want to work on machine learning and AI development".

Comments (4 posted)

Distributions quote of the week

I think you are reading lack of interest or opposition into a situation where the primary problem is lack of resources.

I would love to solve this. I do not like the status quo. I certainly don't think the status quo is fantastic. I'm also massively behind on the packages that I already agreed to be responsible for and other Debian work that I am supposed to be doing, and given that my day job exhausts nearly all of my available energy for high-interaction discussions, I don't have the bandwidth to mentor newcomers. I suspect this is a very common problem among experienced Debian maintainers.

This says bad things about the project's sustainability and I think everyone knows that. No one thinks the situation is good. But knowing that things need to improve does not create the time and energy required to improve them; in fact, in my experience, it sadly often does the opposite.

It's a trap and I'm not sure how to get out of it, but the problem isn't lack of caring. It's that we have to figure out a way to get out of the trap without piling more work on people who can't handle more and will start dropping even more things if people insist.

— Russ Allbery

Comments (none posted)

Development quote of the week

As far as I know, nobody who published their writing or their open-source code consented to it being collected en masse, [indiscriminately], and thrown into a blender to develop a system whose purpose, as defined by its developers (or at least their financial backers), is explicitly to replace human work for the profit of those developers and backers.

Regardless of whether generative models produce output that counts as plagiarism, I think the lack of consent is itself a problem.

— Matt Campbell

Comments (none posted)