destinyland writes: LWN has a terrific update what's happened since the discovery of University of Minnesota researchers intentionally submitting buggy code to the Linux kernel:

The writing of a paper on this research [PDF] was not the immediate cause of the recent events; instead, it was the posting of a buggy patch originating from an experimental static-analysis tool run by another developer at UMN. That led developers in the kernel community to suspect that the effort to submit intentionally malicious patches was still ongoing. Since then, it has become apparent that this is not the case, but by the time the full story became clear, the discussion was already running at full speed.

The old saying still holds true: one should not attribute to malice that which can be adequately explained by incompetence.

On April 22, a brief statement was issued by the Linux Foundation technical advisory board (TAB) stating that, among other things, the recent patches appeared to have been submitted in good faith.

Meanwhile, the Linux Foundation and the TAB sent a letter to the UMN researchers outlining how the situation should be addressed; that letter has not been publicly posted, but ZDNet apparently got a copy from somewhere. Among other things, the letter asked for a complete disclosure of the buggy patches sent as part of the UMN project and the withdrawal of the paper resulting from this work.

In response, the UMN researchers posted an open letter apologizing to the community, followed a few days later by a summary of the work they did [PDF] as part of the "hypocrite commits" project. Five patches were submitted overall from two sock-puppet accounts, but one of those was an ordinary bug fix that was sent from the wrong account by mistake. Of the remaining four, one of them was an attempt to insert a bug that was, itself, buggy, so the patch was actually valid; the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers, though the reasons for rejection were not always the bugs in question.

The paper itself has been withdrawn and will not be presented in May as was planned...

One of the first things that happened when this whole affair exploded was the posting by Greg Kroah-Hartman of a 190-part patch series reverting as many patches from UMN as he could find... As it happens, these "easy reverts" also needed manual review; once the initial anger passed there was little desire to revert patches that were not actually buggy. That review process has been ongoing over the course of the last week and has involved the efforts of a number of developers. Most of the suspect patches have turned out to be acceptable, if not great, and have been removed from the revert list; if your editor's count is correct, 42 patches are still set to be pulled out of the kernel...

A look at the full set of UMN patches reinforces some early impressions, though. First is that almost all of them do address some sort of real (if obscure and hard to hit) problem...

Saturday University of Minnesota researchers emailed the Linux kernel mailing list apologizing for submitting buggy code as part of a research project to see whether it would be accepted.

Late Saturday night, the kernel team's Greg Kroah-Hartman replied: Thank you for your response.

As you know, the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.

Until those actions are taken, we do not have anything further to discuss about this issue.

thanks

Earlier this week Greg Kroah-Hartman of the Linux kernel development team banned the University of Minnesota from contributing after researchers there submitted what he called "obviously-incorrect patches" believed to be part of a research project into whether buggy code would be accepted.

Today the professor in charge of that project, as well as two of its researchers, sent an email to the Linux kernel mailing list saying they "sincerely apologize for any harm our research group did to the Linux kernel community." Our goal was to identify issues with the patching process and ways to address them, and we are very sorry that the method used in the "hypocrite commits" paper was inappropriate. As many observers have pointed out to us, we made a mistake by not finding a way to consult with the community and obtain permission before running this study; we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches. While our goal was to improve the security of Linux, we now understand that it was hurtful to the community to make it a subject of our research, and to waste its effort reviewing these patches without its knowledge or permission.

We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about finding and fixing security vulnerabilities... We are a research group whose members devote their careers to improving the Linux kernel. We have been working on finding and patching vulnerabilities in Linux for the past five years...

This current incident has caused a great deal of anger in the Linux community toward us, the research group, and the University of Minnesota. We apologize unconditionally for what we now recognize was a breach of the shared trust in the open source community and seek forgiveness for our missteps. We seek to rebuild the relationship with the Linux Foundation and the Linux community from a place of humility to create a foundation from which, we hope, we can once again contribute to our shared goal of improving the quality and security of Linux software... We are committed to following best practices for collaborative research by consulting with community leaders and members about the nature of our research projects, and ensuring that our work meets not only the requirements of the Institutional Review Board but also the expectations that the community has articulated to us in the wake of this incident.

While this issue has been painful for us as well, and we are genuinely sorry for the extra work that the Linux kernel community has undertaken, we have learned some important lessons about research with the open source community from this incident. We can and will do better, and we believe we have much to contribute in the future, and will work hard to regain your trust.
Their email also says their work did not introduce vulnerabilities into the Linux code. ("The three incorrect patches were discussed and stopped during exchanges in a Linux message board, and never committed to the code.")

And the email also clarifies that their research was only done in August of 2020, and "All the other 190 patches being reverted and re-evaluated were submitted as part of other projects and as a service to the community; they are not related to the 'hypocrite commits' paper. These 190 patches were in response to real bugs in the code and all correct — as far as we can discern — when we submitted them... Our recent patches in April 2021 are not part of the 'hypocrite commits' paper either."

UPDATE (4/25): Late Saturday night the kernel team's Greg Kroah-Hartman rejected the apology, writing that "the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.

"Until those actions are taken, we do not have anything further to discuss about this issue."

jonesy16 writes: While users have long been able to run Linux GUI apps on Windows by installing a separate X Server, this marks the first time that native support is available through the Windows Subsystem for Linux (WSL). Audio support and hardware acceleration are also provided, seemingly enabling a limitless set of use cases for those wishing to live the dual OS life. The change is identified in the recent preview build release along with a more in-depth discussion of the graphical subsystem now called WSLg.

Canonical released Ubuntu 21.04 with native Microsoft Active Directory integration, Wayland graphics by default, and a Flutter application development SDK. Separately, Canonical and Microsoft have announced performance optimization and joint support for Microsoft SQL Server on Ubuntu. Canonical blog adds: "Native Active Directory integration and certified Microsoft SQL Server on Ubuntu are top priorities for our enterprise customers." said Mark Shuttleworth, CEO of Canonical. "For developers and innovators, Ubuntu 21.04 delivers Wayland and Flutter for smoother graphics and clean, beautiful, design-led cross-platform development." You can read the full list of new features and changelog here.

Greg Kroah-Hartman, who is one of the head honchos of the Linux kernel development and maintenance team, has banned the University of Minnesota (UMN) from further contributing to the Linux Kernel. The University had apparently introduced questionable patches into the kernel of Linux. From a report: The UMN had worked on a research paper dubbed "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits". Obviously, the "Open-Source Software" (OSS) here is indicating the Linux kernel and the University had stealthily introduced Use-After-Free (UAF) vulnerability to test the susceptibility of Linux. So far so good perhaps as one can see it as ethical experimenting. However, the UMN apparently sent another round of "obviously-incorrect patches" into the kernel in the form of "a new static analyzer" causing distaste to Greg Kroah-Hartman who has now decided to ban the University from making any further contributions.

An anonymous reader writes: Debian Project Secretary Kurt Roeckx has announced the results of a closely-watched vote on what statement would be made about Richard Stallman's readmission to the Free Software Foundation's board.
Seven options were considered, with the Debian project's 420 voting developers also asked to rank their preferred outcomes:

• Option 1: "Call for the FSF board removal, as in rms-open-letter.github.io"

• Option 2: "Call for Stallman's resignation from all FSF bodies"

• Option 3: "Discourage collaboration with the FSF while Stallman is in a leading position"

• Option 4: "Call on the FSF to further its governance processes"

• Option 5: "Support Stallman's reinstatement, as in rms-support-letter.github.io"

• Option 6: "Denounce the witch-hunt against RMS and the FSF"

• Option 7: "Debian will not issue a public statement on this issue"

While all seven options achieved a quorum of votes, two failed to achieve a majority — options 5 and 6. ("Support Stallman's reinstatement" and "Denounce the witch-hunt...") The option receiving the most votes was #7 (not issuing a public statement) — but it wasn't that simple. The vote's final outcome was determined by comparing every possible pair of options to determine which option would still be preferred by a majority of voters in each possible comparision.

In this case, that winner was still the option which had also received the most votes:


Debian will not issue a public statement on this issue.
The Debian Project will not issue a public statement on whether Richard Stallman should be removed from leadership positions or not.

Any individual (including Debian members) wishing to (co-)sign any of the open letters on this subject is invited to do this in a personal capacity.


The results are captured in an elaborate graph. Numbers inside the ovals show the final ratio of yes to no votes (so a number higher than 1.00 indicates a majority, with much higher numbers indicating much larger majorities). Numbers outside the ovals (along the lines) indicate the number of voters who'd preferred the winning choice over the losing choice (toward which the arrow is pointing).

The winning option is highlighted in blue.

Long-time Slashdot reader xiando shares news from LinuxReviews: Linux Kernel Runtime Guard (LKRG) is a security module for the Linux kernel developed by Openwall. The latest release adds compatibility with Linux kernels up to soon to be released 5.12, support for building LKRG into kernel images, support for old 32-bit x86 machines and more...

The Linux Kernel Runtime Guard is an out-of-tree kernel module you can install as a kernel module, or, with the 0.9.0 release, build into your Linux kernel. It does run-time integrity checks to detect security vulnerability exploits against the Linux kernel.
An Openwall developer also notes in the announcement that "During LKRG development and testing I've found 7 Linux kernel bugs, 4 of them have CVE numbers."

Slashdot reader LeeLynx shares news from The Register about a Slackware 15 beta release (following the debut of February's alpha), "nearly five years after the distribution last saw a major update." (And nearly 28 years after its initial release back in 1993...) Created by Patrick Volkerding (who still lays claim to the title Benevolent Dictator For Life), the current release version arrived in the form of 2016's 14.2... The Linux kernel has been updated to 5.10.30 (at time of writing) with 5.11.14 available for testing. Desktop fans may be pleased to see, among the many updates, KDE Plasma hitting 5.21.4 as well as updates for old faithfuls, such as Mozilla Firefox and Thunderbird.

The beta itself dropped on 12 April (with the 5.10.29 kernel) and Volkerding noted: "I'm going to go ahead and call this a beta even though there's still no fix for the illegal instruction issue with 32-bit mariadb. But there should be soon."

Tinkering has continued since, judging by the change log, although the beta tag brings hope there will be a release before long.

Google's Android team supports Rust for developing the Android operating system. Now they're also helping evaluate Rust for Linux kernel development. Their hopes, among other things, are that "New code written in Rust has a reduced risk of memory safety bugs, data races and logic bugs overall," that "abstractions that are easier to reason about," and "More people get involved overall in developing the kernel, thanks to the usage of a modern language."

Linus Torvalds responded in a new interview with IT Wire (shared by Slashdot reader juul_advocate): The first patches for Rust support in the Linux kernel have been posted and the man behind the kernel says the fact that these are being discussed is much more important than a long post by Google about the language. Linus Torvalds told iTWire in response to queries that Rust support was "not there yet", adding that things were "getting to the point where maybe it might be mergeable for 5.14 or something like that..." Torvalds said that it was still early days for Rust support, "but at least it's in a 'this kind of works, there's an example, we can build on it'."

Asked about a suggestion by a commenter on the Linux Weekly News website, who said, during a discussion on the Google post, "The solution here is simple: just use C++ instead of Rust", Torvalds could not restrain himself from chortling. "LOL," was his response. "C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language.

"For people who don't like C, go to a language that actually offers you something worthwhile. Like languages with memory safety and [which] can avoid some of the dangers of C, or languages that have internal GC [garbage collection] support and make memory management easier. C++ solves all the wrong problems, and anybody who says 'rewrite the kernel in C++' is too ignorant to even know that."

He said that when one spoke of the dangers of C, one was also speaking about part of what made C so powerful, "and allows you to implement all those low-level things efficiently".
Torvalds added that, while garbage collection is "a very good thing in most other situations," it's "generally not necessarily something you can do in a low-level system programming."

Long-time Slashdot reader xiando quotes LinuxReviews: The community distribution Arch Linux has up to now required you to manually install it by entering a whole lot of scary commands in a terminal. Arch version 2021.04.01 features a new guided installer [reached by] typing python -m archinstall guided into the console you get when you boot the Arch Linux installation ISO.

It is not very novice-friendly, or user-friendly, but it gets the job done and it will work fine for those with some basic GNU/Linux knowledge.
Tech Radar writes that previously Arch Linux had "a rather convoluted installation process, which has given rise to a stream of Arch-based distros that are easier to install," adding that the new installer "was reportedly promoted as an official installation mechanism back in January, and was actively worked upon leading to its inclusion in the installation medium." Users have been calling on Arch Linux for simplifying the installation process for a long time, to bring it in line with other Linux distros. However, the Arch philosophy has always been to put the users in charge of every aspect of their installation, which is the antithesis of automated installers.
Phoronix calls the new installer "very quick and easy," although "granted not as user-friendly / polished as say the Debian Installer, Red Hat's Anaconda installer, even Ubuntu's Subiquity, and other TUI/GUI Linux installers out there." They also note that Archinstall "does allow automatically partitioning the drive with your choice of file-system options, automatically installing a desktop environment if desired, configuring the network interfaces, and all the other basics." The method is quick enough that I'll likely use archinstall for future Arch Linux benchmarks on Phoronix as it also then applies a sane set of defaults for users... Five minutes or less and off to the races, ready for Arch Linux."
But Slashdot reader I75BJC still favors "scary commands in a terminal," leaving this comment on the original submission: If you can't type with the big adults, stay on your PlayStation.

Even Apple, with its very good GUI has a command line. The command line commands are more flexible, more specific, more subtle than the pointy-clicky GUI.

IBM has announced a COBOL compiler for Linux on x86. "IBM COBOL for Linux on x86 1.1 brings IBM's COBOL compilation technologies and capabilities to the Linux on x86 environment," said IBM in an announcement, describing it as "the latest addition to the IBM COBOL compiler family, which includes Enterprise COBOL for z/OS and COBOL for AIX." The Register reports: COBOL -- the common business-oriented language -- has its roots in the 1950s and is synonymous with the mainframe age and difficulties paying down technical debt accrued since a bygone era of computing. So why is IBM -- which is today obsessed with hybrid clouds -- bothering to offer a COBOL compiler for Linux on x86? Because IBM thinks you may want your COBOL apps in a hybrid cloud, albeit the kind of hybrid IBM fancies, which can mean a mix of z/OS, AIX, mainframes, POWER systems and actual public clouds.
[...]
But the announcement also suggests IBM doesn't completely believe this COBOL on x86 Linux caper has a future as it concludes: "This solution also provides organizations with the flexibility to move workloads back to IBM Z should performance and throughput requirements increase, or to share business logic and data with CICS Transaction Server for z/OS." The new offering requires RHEL 7.8 or later, or Ubuntu Server 16.04 LTS, 18.04 LTS, or later.

New submitter juul_advocate shares a report from iTWire: The outcome of a general resolution proposed by the Debian GNU/Linux project, to decide how to react to the return of Free Software Foundation founder Richard Stallman to the board, will be known on April 17, with voting now underway. The original proposal for a GR was made by Steve Langasek, who also works for Canonical, the company behind Ubuntu, and calls for co-signing an existing letter which wants Stallman gone and the FSF board sacked. There has been a lot of discussion around the issue.

Six alternatives have been proposed. The proposals are:
- remove the entire FSF board as in an existing letter;
- seek Stallman's resignation from all FSF bodies;
- discourage collaboration with the FSF while Stallman remains in a leading position;
- ask FSF to further its governance processes;
- support Stallman's reinstatement;
- denounce the witch hunt against Stallman and the FSF; and
- issue no public statement on the issue. During the organization's LibrePlanet virtual event on March 19, Stallman announced that he was rejoining the board and does not intend to resign again. His return has drawn condemnation from many people in the free software community. Just days after his announcement, an open letter calling for Stallman to be removed again and for the FSF's entire board to resign was signed by hundreds of people.

Linux giant Red Hat has decided to pull funding, while the 'Open Source Initiative' said that it "will not participate in any events that include Richard M. Stallman," adding that it "cannot collaborate with the Free Software Foundation until Stallman is removed from the organization's leadership."

Long-time Slashdot reader xiando quotes the backstory from LinuxReviews.org: CentOS used to be the go-to alternative for those who wanted to use Red Hat Enterprise Linux (RHEL) without having to pay RedHat to use it. It was a almost 1:1 clone until RedHat took control of it and turned it into what is now a RHEL beta-version, not a stable RHEL release without the branding. Almalinux is one of several projects that have made their own RHEL forks in response. The first Almalinux version is now released.
ZDNet notes that CentOS co-founder Gregory Kurtzer has announced his own RHEL clone and CentOS replacement named Rocky Linux. But they offer this report on AlmaLinux: CloudLinux — which was founded in 2009 to provide a customized, high-performance, lightweight RHEL/CentOS server clone for multitenancy web and server hosting companies — came ready to deliver. The new free AlmaLinux is now stable and ready for production workloads. The company also announced the formation of a non-profit organization: AlmaLinux Open Source Foundation. This group will take over managing the AlmaLinux project going forward. CloudLinux has committed a $1 million annual endowment to support the project.

Jack Aboutboul, former Red Hat and Fedora engineer and architect, will be AlmaLinux's community manager. Altogether, Aboutboul brings over 20 years of experience in open-source communities as a participant, manager, and evangelist... "In an effort to fill the void soon to be left by the demise of CentOS as a stable release, AlmaLinux has been developed in close collaboration with the Linux community," said Aboutaboul in a statement. "These efforts resulted in a production-ready alternative to CentOS that is supported by community members...."

In talking with CentOS business users, who deployed CentOS on web and host servers, I found many of them to be very hopeful about AlmaLinux. One from a mid-Atlantic-based Linux hosting company said, "What we want is a stable Linux that our customers can rely on from year to year. Since CentOS Stream can't deliver that, we think — hope — that AlmaLinux can do it for us and our users instead...."

This first release of AlmaLinux is a one-to-one binary compatible fork of RHEL 8.3. Looking ahead, AlmaLinux will seek to keep step-in-step with future RHEL releases... The GitHub page has already been published and the completed source code has been published in the main download repository. The CloudLinux engineering team has also published FAQ on AlmaLinux Wiki.
"The sudden shift in direction for CentOS that was announced in December created a big void for millions of CentOS users," said Simon Phipps, open source advocate and a former president of the Open Source Initiative who is on the governing board of the AlmaLinux project. In a statement, Phipps said that "As a drop-in open-source replacement, AlmaLinux provides those users with continuity and new opportunity to be part of a vibrant community built around creating and supporting this new Linux distribution under non-profit governance.

"I give a lot of credit to CloudLinux for stepping in to offer CentOS users a lifeline to continue with AlmaLinux."

wiredog shares a ZDNet report: I have literally been covering SCO's legal attempts to prove that IBM illegally copied Unix's source code into Linux for over 17 years. I've written well over 500 stories on this lawsuit and its variants. I really thought it was dead, done, and buried. I was wrong. Xinuos, which bought SCO's Unix products and intellectual property (IP) in 2011, like a bad zombie movie, is now suing IBM and Red Hat [for] "illegally Copying Xinuos' software code for its server operating systems." For those of you who haven't been around for this epic IP lawsuit, you can get the full story with "27 eight-by-ten color glossy photographs and circles and arrows and a paragraph on the back of each one" from Groklaw. If you'd rather not spend a couple of weeks going over the cases, here's my shortened version. Back in 2001, SCO, a Unix company, joined forces with Caldera, a Linux company, to form what should have been a major Red Hat rival. Instead, two years later, SCO sued IBM in an all-out legal attack against Linux.

The fact that most of you don't know either company's name gives you an idea of how well that lawsuit went. SCO's Linux lawsuit made no sense and no one at the time gave it much of a chance of succeeding. Over time it was revealed that Microsoft had been using SCO as a sock puppet against Linux. Unfortunately for Microsoft and SCO, it soon became abundantly clear that SCO didn't have a real case against Linux and its allies. SCO lost battle after battle. The fatal blow came in 2007 when SCO was proven to have never owned the copyrights to Unix. So, by 2011, the only thing of value left in SCO, its Unix operating systems, was sold to UnXis. This acquisition, which puzzled most, actually made some sense. SCO's Unix products, OpenServer and Unixware, still had a small, but real market. At the time, UnXis now under the name, Xinuos, stated it had no interest in SCO's worthless lawsuits. In 2016, CEO Sean Synder said, "We are not SCO. We are investors who bought the products. We did not buy the ability to pursue litigation against IBM, and we have absolutely no interest in that." So, what changed? The company appears to have fallen on hard times. As Synder stated: "systems, like our FreeBSD-based OpenServer 10, have been pushed out of the market." Officially, in his statement, Snyder now says, "While this case is about Xinuos and the theft of our intellectual property, it is also about market manipulation that has harmed consumers, competitors, the open-source community, and innovation itself."

nickwinlund77 shares a report from The Register: The chorus of disapproval over Richard M Stallman, founder and former president of the Free Software Foundation (FSF), rejoining the organization has intensified as Linux giant Red Hat confirmed it was pulling funding. Stallman announced he had returned to the FSF's Board of Directors last weekend -- news that has not gone down well with all in the community and Red Hat is the latest to register its dismay.

CTO Chris Wright tweeted overnight: "I am really outraged by FSF's decision to reinstate RMS. At a moment in time where diversity and inclusion awareness is growing, this is a step backwards." Describing itself as "appalled" at the return of Stallman to the FSF board of directors "considering the circumstances of Richard Stallman's original resignation in 2019," Red Hat said it decided to act. "We are immediately suspending all Red Hat funding of the FSF and any FSF-hosted events. In addition, many Red Hat contributors have told us they no longer plan to participate in FSF-led or backed events, and we stand behind them," said Red Hat.

An anonymous reader shares an excerpt from a ZDNet article, written by Steven J. Vaughan-Nichols: Linux is the poster-child for the C language. But times change. The Rust language has been slowly gathering support for use as a system language in Linux. For example, at the 2020 Linux Plumbers Conference, developers gave serious thought to using the Rust language for new Linux inline code. So, where is it today? I asked Linux's creator, Linus Torvalds, and the Linux stable kernel maintainer Greg Kroah-Hartman for their thoughts. [...] What does Torvalds make of all this? He's in "the 'wait and see' camp -- I'm interested in the project, but I think it's driven by people who are very excited about Rust, and I want to see how it actually then ends up working in practice." "Personally," Torvalds is "in no way "pushing" for Rust, [but] I'm open to it considering the promised advantages and avoiding some safety pitfalls, but I also know that sometimes promises don't pan out."

Torvalds thinks "Rust's primary first target seems to be drivers, simply because that's where you find just a lot of different possible targets, and you have these individual parts of the kernel that are fairly small and independent. That may not be a very interesting target to some people, but it's the obvious one." Another point is taking on drivers first for "any initial trials to drivers is simply the architecture side," said Torvalds. "Lots of drivers are only relevant on a couple of target architectures, so the whole issue with Rust code not being supported on some architectures is less of an issue." Kroah-Hartman agrees that "drivers are probably the first place for an attempt like this as they are the 'end leafs' of the tree of dependencies in the kernel source. They depend on core kernel functionality, but nothing depends on them."

Torvalds knows some people don't like the idea of Rust in userspace at all. "People complain[ing] about "Rustification" in userspace isn't a great sign for any future kernel use, but hey, we'll see. The kernel is different from userspace projects -- more difficult in some respects (we use a lot of very odd header files that pushes the boundary of what can be called "C"), but easier in many other respects (mainly in the sense that the kernel is fairly self-contained, and then doesn't rely on other projects for the final binary)." From where Kroah-Hartman sits, "it will all come down to how well the interaction between the kernel core structures and lifetime rules that are written in C can be mapped into Rust structures and lifetime rules for drivers in Rust to be able to use them properly. That's going to take a lot of careful work by the developers wanting to hook this all up and I wish them the best of luck."

In his This Week in Programming column, Mike Melanson writes: Rustaceans' dreams of Rust's inclusion in the Linux kernel are one tiny, ever so slight step closer to becoming a reality, with this week's "intentionally bare-bones" inclusion in Linux-next, the development branch of the Linux kernel... Curb your enthusiasm, however, as this remains a rather tentative first step of many necessary steps before Rust fully lands in the Linux kernel.

A rather brief post on LWN.net summarizes where we are rather succinctly:

Followers of the linux-next integration tree may have noticed a significant addition: initial support for writing device drivers in the Rust language. There is some documentation in Documentation/rust, while the code itself is in the rust top-level directory. Appearance in linux-next generally implies readiness for the upcoming merge window, but it is not clear if that is the case here; this code has not seen a lot of wider review yet. It is, regardless, an important step toward the ability to write drivers in a safer language.

Indeed, Miguel Ojeda, a software developer and maintainer of the Rust for Linux project writes that the proposed inclusion "does not mean we will make it into mainline, of course, but it is a nice step to make things as smooth as possible," with some changes expected before any decision as to Rust's inclusion are made.

For those of you less familiar with Rust, part of the appeal here comes with Rust's memory safety features, especially in comparison to C, which the Linux kernel is currently coded in. Part of the problem, however, is that Rust is compiled based on LLVM, as opposed to GCC, and subsequently supports fewer architectures. This is a problem we've seen play out recently, as the Python cryptography library has replaced some old C code with Rust, leading to a situation where certain architectures will not be supported. Presently, the proposal to include Rust in the Linux kernel limits this issue by saying that Rust would be used, at least initially, for writing drivers that, as noted in another LWN.net article on the topic, "would never be used on the more obscure architectures anyway."

"Three recently unearthed vulnerabilities in the Linux kernel, located in the iSCSI module used for accessing shared data storage facilities, could allow root privileges to anyone with a user account," reports SC Media: "If you already had execution on a box, either because you have a user account on the machine, or you've compromised some service that doesn't have repaired permissions, you can do whatever you want basically," said Adam Nichols, principal of the Software Security practice at GRIMM. While the vulnerabilities "are in code that is not remotely accessible, so this isn't like a remote exploit," said Nichols, they are still troublesome. They take "any existing threat that might be there. It just makes it that much worse," he explained. "And if you have users on the system that you don't really trust with root access it, it breaks them as well."

Referring to the theory that 'many eyes make all bugs shallow,' Linux code "is not getting many eyes or the eyes are looking at it and saying that seems fine," said Nichols. "But, [the bugs] have been in there since the code was first written, and they haven't really changed over the last 15 years...." That the flaws slipped detection for so long has a lot to do with the sprawl of the the Linux kernel. It "has gotten so big" and "there's so much code there," said Nichols. "The real strategy is make sure you're loading as little code as possible."

The bugs are in all Linux distributions, Nichols said, although the kernel driver is not loaded by default. Whether a normal user can load the vulnerable kernel module varies. They can, for instance, on all Red Hat based distros that GRIMM tested, he said. "Even though it's not loaded by default, you can get it loaded and then of course you can exploit it without any trouble...."

The bugs have been patched in the following kernel releases: 5.11.4, 5.10.21, 5.4.103, 4.19.179, 4.14.224, 4.9.260, and 4.4.260. All older kernels are end-of- life and will not receive patches.

An official version of the popular 7-zip archiving program has been released for Linux for the first time. Bleeping Computer reports: Linux already had support for the 7-zip archive file format through a POSIX port called p7zip but it was maintained by a different developer. As the p7zip developer has not maintained their project for 4-5 years, 7-Zip developer Igor Pavlov decided to create a new official Linux version based on the latest 7-Zip source code. Pavlov has released 7-Zip for Linux in AMD64, ARM64, x86, and armhf versions, which users can download [via their respective links].

"These new 7-Zip binaries for Linux were linked (compiled) by GCC without -static switch. And compiled 32-bit executables (x86 and armhf) didn't work on some arm64 and amd64 systems, probably because of missing of some required .so files." "Please write here, if you have some advices how to compile and link binaries that will work in most Linux systems," Pavlov stated on his release page.