All posts by corbet

[$] Hardening the kernel against heap-spraying attacks

Post Syndicated from corbet original https://lwn.net/Articles/965837/

While a programming error in the kernel may be subject to direct
exploitation, usually a more roundabout approach is required to take
advantage of a security bug. One popular approach for those wishing to
take advantage of vulnerabilities is heap spraying, and
it has often been employed to compromise the kernel. In the future,
though, heap-spraying attacks may be a bit harder to pull off, thanks to the
“dedicated bucket allocator”
proposed by Kees Cook.

Redis is no longer free software

Post Syndicated from corbet original https://lwn.net/Articles/966133/

The Redis in-memory database system has had
its license changed
to either the Redis Source Available
License
or the Server Side
Public License
(covered here in 2018);
neither license qualifies as free software.

Under the new license, cloud service providers hosting Redis
offerings will no longer be permitted to use the source code of
Redis free of charge. For example, cloud service providers will be
able to deliver Redis 7.4 only after agreeing to licensing terms
with Redis, the maintainers of the Redis code.

Distributors like Fedora are already looking
at
removing Redis as a consequence. (Thanks to Emmanuel Seyman).

The “Nova” driver for NVIDIA chipsets

Post Syndicated from corbet original https://lwn.net/Articles/966129/

Danilo Krummrich has announced the
existence of the “Nova” project within Red Hat.

We just started to work on Nova, a Rust-based GSP-only driver for
Nvidia GPUs. Nova, in the long term, is intended to serve as the
successor of Nouveau for GSP-firmware-based GPUs.

With Nova we see the chance to significantly decrease the
complexity of the driver compared to Nouveau for mainly two
reasons. First, Nouveau’s historic architecture, especially around
nvif/nvkm, is rather complicated and inflexible and requires major
rework to solve certain problems (such as locking hierarchy in VMM
/ MMU code for VM_BIND currently being solved with a workaround)
and second, with a GSP-only driver there is no need to maintain
compatibility with pre-GSP code.

Besides that, we also want to take the chance to contribute to the
Rust efforts in the kernel and benefit from from more memory safety
offered by the Rust programming language.

Given that the effort has just begun, it will be a while before this driver
shows up in a distribution release.

GNOME 46 released

Post Syndicated from corbet original https://lwn.net/Articles/966096/

Version 46 of the GNOME desktop
has been released. “GNOME 46 is code-named ‘Kathmandu’, in recognition
of the amazing work done by the organizers of GNOME.Asia 2023.

Significant changes include a new global search feature, enhancements to
the Files app, improved remote login support, and more.

Security updates for Tuesday

Post Syndicated from corbet original https://lwn.net/Articles/965958/

Security updates have been issued by Debian (cacti, postgresql-11, and zfs-linux), Fedora (freeimage, mingw-expat, and mingw-freeimage), Mageia (apache-mod_security-crs, expat, and multipath-tools), Oracle (.NET 7.0 and kernel), Red Hat (kernel, kernel-rt, and kpatch-patch), and Ubuntu (bash, kernel, linux, linux-aws, linux-hwe, linux-kvm, linux-oracle, linux, linux-aws, linux-kvm, linux-lts-xenial, and vim).

Man Yue Mo: Gaining kernel code execution on an MTE-enabled Pixel 8

Post Syndicated from corbet original https://lwn.net/Articles/965926/

Man Yue Mo explains
how to compromise a Pixel 8 phone
even when the Arm memory-tagging extension is in use, by taking
advantage of the Mali GPU.

So, by using the GPU to access physical addresses directly, I’m
able to completely bypass the protection that MTE
offers. Ultimately, there is no memory safe code in the code that
manages memory accesses. At some point, physical addresses will
have to be used directly to access memory.

[$] Toward a real “too small to fail” rule

Post Syndicated from corbet original https://lwn.net/Articles/964793/

Kernel developers have long been told that any attempt to allocate memory
might fail, so their code must be prepared for memory to be unavailable.
Informally, though, the kernel’s memory-management subsystem implements a
policy whereby requests below a certain size will not fail (in process
context, at least), regardless of
how tight memory may be. A recent discussion on the linux-mm list has
looked at the idea of making the “too small to
fail” rule
a policy that developers can rely on.

[$] A new filesystem for pidfds

Post Syndicated from corbet original https://lwn.net/Articles/963749/

The pidfd abstraction is a Linux-specific
way of referring to processes that avoids the race conditions inherent in
Unix process ID numbers. Since a pidfd is a file descriptor, it needs a
filesystem to implement the usual operations performed on files. As the
use of pidfds has grown, they have stressed the limits of the simple
filesystem that was created for them. Christian Brauner has created
a new filesystem for pidfds
that seems likely to debut in the 6.9
kernel, but it ran into a little bump along the way, demonstrating that
things you cannot see can still hurt you.

Today’s hardware vulnerability: register file data sampling

Post Syndicated from corbet original https://lwn.net/Articles/965167/

The mainline kernel has just received a set of commits addressing the
“register file data sampling” hardware vulnerability.

RFDS may allow a malicious actor to infer data values previously
used in floating point registers, vector registers, or integer
registers. RFDS does not provide the ability to choose which data
is inferred

Only Atom cores are affected, but those cores can be found inside a number
of processors. See this documentation
commit
for more information.

Security updates for Tuesday

Post Syndicated from corbet original https://lwn.net/Articles/965113/

Security updates have been issued by Debian (qemu), Mageia (libtiff and thunderbird), Red Hat (kernel, kpatch-patch, postgresql, and rhc-worker-script), SUSE (compat-openssl098, openssl, openssl1, python-Django, python-Django1, and wpa_supplicant), and Ubuntu (accountsservice, libxml2, linux-bluefield, linux-raspi-5.4, linux-xilinx-zynqmp, linux-oem-6.1, openvswitch, postgresql-9.5, and ruby-rack).

Huston: KeyTrap!

Post Syndicated from corbet original https://lwn.net/Articles/965067/

Geoff Huston digs into the
details
of the KeyTrap DNS vulnerability, which was disclosed in February.

It’s by no means “devasting” for the DNS, and the fix is much the
same as the previous fix. As well as limiting the number of queries
that a resolver can generate to resolve a queried name, a careful
resolver will limit both the elapsed time and perhaps the amount of
the resolver’s processing resources that are used to resolve any
single query name.

It’s also not a novel discovery by the ATHENE folk. The
vulnerability was described five years ago by a student at the
University of Twente. I guess the issue was that the student failed
to use a sufficient number of hysterical adjectives in describing
this DNS vulnerability in the paper!

[$] Development statistics for 6.8

Post Syndicated from corbet original https://lwn.net/Articles/964106/

The 6.8 kernel was released on March 10
after a typical, nine-week development cycle. Over this time, 1,938
developers contributed 14,405 non-merge changesets, making 6.8 into a
slower cycle than 6.7 (but busier than 6.6), with the lowest number of
developers participating since the 6.5 release. Still, there was
a lot going on during this cycle; read on for some of the details.

The 6.8 kernel has been released

Post Syndicated from corbet original https://lwn.net/Articles/964784/

Linus has released the 6.8 kernel.

So it took a bit longer for the commit counts to come down this
release than I tend to prefer, but a lot of that seemed to be about
various selftest updates (networking in particular) rather than any
actual real sign of problems. And the last two weeks have been
pretty quiet, so I feel there’s no real reason to delay 6.8.

Significant changes in this release include
the deadline servers scheduling feature,
support for memory-management
auto-tuning
in DAMON,
the large anonymous folios feature,
the kernel
samepage merging advisor
,
the ability to prevent writes to block
devices containing mounted filesystems,
the listmount() and
statmount() system calls
,
the first
device driver written in Rust
,
the removal
of the (never finished) bpfilter
packet-filtering system,
three new system calls for managing Linux
security modules,
the BPF token mechanism for fine-grained
control over BPF permissions,
support for data-type profiling in the
perf tool,
guest-first memory for KVM virtualization,
the Intel Xe graphics driver,
and a lot more. See the LWN merge-window summaries
(part 1,
part 2) for more information.