#Linux 6.12 is out. For a list of new features see:

* This short LWN story: https://lwn.net/Articles/997958/ (screenshotted)

* Two detailed stories from LWN: https://lwn.net/Articles/990750/ & https://lwn.net/Articles/991301/

* The kernelnewbies page: https://kernelnewbies.org/Linux_6.12

See also the announcement from @torvalds:

https://lore.kernel.org/lkml/CAHk-=wgtGkHshfvaAe_O2ntnFBH3EprNk1juieLmjcF2HBwBgQ@mail.gmail.com/

'"No strange surprises this last week, so we're sticking to the regular release schedule, and that obviously means that the merge window opens tomorrow."'

#kernel #LinuxKernel

@gustavoars I'm not even going to try :)

{sigh} Go home CodeQL, you are drunk…

int main(int argc, char *argv[])
Poorly documented function: fewer than 2% comments for a function of 129 lines.

Code in question is at: https://github.com/gregkh/usbutils/blob/master/lsusb.c#L3835 if people are curious. It’s as if the tool hasn’t seen C code before…

To followup up on this, @xexaxo sent a pull request to get rid of these "code in the meson temp files are security issues" false-warnings: https://github.com/gregkh/usbutils/pull/211

Many thanks for this, now to whittle down the other pointless `switch case is too big` and `FIXME is left in a comment` warnings that are left so that if anything "real" ever shows up, it will actually be noticed...

@xexaxo Yes, thank you! And thanks for the PR, I'll go merge that now and see how it goes.

@tbodt Nope, didn't work. Or I got the yaml wrong, which is probably the real reason here...

@tbodt Oh, nice, let me attempt that...

@tbodt codeql really wants to build the code, as I'm guessing it is doing so with a compiler hack to get at the files needed to analyze. I guess we can turn that off, let me try that out...

@tbodt @captainepoch Yes, enabling it is good. Stupid tests claiming problems that are not actually present at all are not good.

Drowns out any potential real issues.

As it turns out that “code scanning” isn’t public, here’s the error message that github is putting up saying that meson temp build files are security problems:

build/meson-private/tmpzhj7u8eq/testfile.c:2  Test

Poor global variable name 'i'. Prefer longer, descriptive names for globals (eg. kMyGlobalConstant, not foo).

Rule ID cpp/short-global-name

Description
This rule finds global variables which have a name of length three characters or less. It is particularly important to use descriptive names for global variables. Use of a clear naming convention for global variables helps document their use, avoids pollution of the namespace and reduces the risk of shadowing with local variables.

@captainepoch Ok, sorry about that. I'll respond to the original with the full error message...

@captainepoch Odd, works for me!

How about this https://github.com/gregkh/usbutils/security/code-scanning

And it's obviously picking up the temp files that meson uses for "does this compiler have this feature" but that's temp files, and not actually in the repo itself. Surely tools like meson are handled properly, right?

Dear lazyweb,

For the usbutils project, developers have helpfully set up a bunch of github actions to help with build tests and the like, and it also includes github's "security scanning" toolsets. Unfortunately the output of such tools is pretty useless and unhelpful to a fault.

Example, this "result": https://github.com/gregkh/usbutils/security/code-scanning/2291
which claims "short global name" yet there is no such actual global variable `i` in the codebase at all.

Because of stuff like this, the tools "claim" there are 63 "security" issues in the usbutils project. Since when did using single character names become a security issue, even if we were doing that, but ok...

So, how to turn this off, or better yet, fix the test to not report issues that are actually in the tests themselves?

@kernellogger @mxk Totally understand.

Here's a link to Todd's latest Plumbers conference calling out how they are going to support devices for 7+ years by moving to new kernel versions over time: https://lpc.events/event/18/contributions/1703/attachments/1391/2998/LPC%202024%20-%20Android%20Device%20Longevity.pdf

@kernellogger @mxk That's not how Android kernels are working anymore. Vendors can have huge numbers of external kernel drivers/modules (i.e. pixel 6 has 300+ of them), but the "core" kernel is managed by Android/Google, in public, in their GKI kernel branches, and that is what is the "base" of the kernel that all vendors can then add drivers to.

If a vendor wants to change the "core" parts of the kernel, they must either submit the changes upstream for merging first (and then backport the change to the GKI kernel and submit it to Android), or somehow convince Android to take it into their GKI kernel (with reasons why upstream rejected it), or add a "hook" to the GKI kernel so that they can put their changes in a kernel module (like many do for scheduler changes.)

The -lts releases get merged into the Android/GKI kernel branches on a monthly basis, which then gets pushed out to all devices "quickly" as there are no in-kernel-abi breaks between the GKI kernel and all external kernel modules used by vendors.

Android has followed the "old" enterprise kernel module here, with the exception of the hook additions, that companies have used for decades (the abi stability changes were taken directly from RHEL and SLES). It's not exciting kernel work, but allows security fixes to get pushed out to devices MUCH faster which is helping everyone out, AND it has forced the vendors to work upstream to get their features merged properly, which has been happening for years now to much success.

There was a plumbers talk all about this this year (and last, and the year before), if you want more details.

@tusooa Heh, you're trying to convince a "Russian identified person" in one of the senior positions in the Linux Foundation that the Linux Foundation is being unfair towards "Russian identified people." It's pretty hilarious.

I'm not a lawyer and I don't speak for the LF, so I won't give you any kind of "official comment." But here's my view of it.

The people removed from maintainer positions were identified as employed by companies on the US and EU sanctions list. These companies are directly involved in the Russian military complex and therefore are directly complicit in war crimes being committed daily in Ukraine. If these maintainers want to think that they are "just techies helping improve the Linux kernel," or that "they are outside of politics," then they are fucking wrong. If they work for companies that develop weaponry or logistics used by the Russian military, they are complicit in Russia's war crimes, and I hold them responsible at a very personal level -- and that's my official comment on the situation.

#usbutils (which contains lsusb and the more modern lsusb.py) 018 is out:

https://lore.kernel.org/all/Zxd0oZefuehqhA7z@kroah.com/

@gregkh writes:

'"For users, the largest change will be that the '-v' option to lsusb will now show the negoitated speed of the device on the bus […], and there is better handling for new device descriptor fields and information in the '-v' output as well."'

@kernellogger And that is why the AUTOSEL bot exists.

@kernellogger NP, and odd that no one actually tagged that commit to be backported to stable kernels... {sigh}

Then here came @gregkh talk about CVE and Rust (see 39:42):

"Rust is going to help us. It'll fix up all the error handling bugs. When you do bad things in memory it just reboots the box... You will get CVE but you won't be able to make a vulnerability out of it."

https://youtu.be/bf3MYWtI4E4?feature=shared