One of the new features in the 5.1 kernel is the pidfd_send_signal() system call. Combined with the (also new) ability to create a file descriptor referring to a process (a "pidfd") by opening its directory in /proc, this system call allows for the sending of signals to processes in a race-free manner. An extension to this feature proposed for 5.2 has, however, sparked a discussion that has brought the whole concept into question. It may yet be that the pidfd feature will be put on hold before the final 5.1 release while the API around it is rethought.
The fundamental problem being addressed by the pidfd concept is process-ID reuse. Most Linux systems have the maximum PID set to 32768; if lots of processes (and threads) are created, it doesn't take a long time to use all of the available PIDs, at which point the kernel will cycle back to the beginning and start reusing the ones that have since become free. That reuse can happen quickly, and processes that work with PIDs might not notice immediately that a PID they hold referred to a process that has exited. In such conditions, a stale PID could be used to send a signal to the wrong process. As Jann Horn pointed out, real vulnerabilities have resulted from this problem.

A pidfd is a file descriptor that is obtained by opening a process's directory in the /proc virtual filesystem; it functions as a reference to the process of interest. If that process exits, its PID might be reused by the kernel, but any pidfds referring to that process will continue to refer to it. Passing a pidfd to pidfd_send_signal() will either signal the correct process (if it still exists), or return an error if the process has exited; it is guaranteed not to signal the wrong process. So it would seem that this problem has been solved.

Memory fragmentation is a constant problem for memory-management subsystems. Over the years, considerable effort has been put into reducing fragmentation in the Linux kernel, but almost all of that work has been focused on memory management at the page level. The slab allocators, which (mostly) manage memory in chunks of less than the page size, have seen less attention, but fragmentation at this level can create problems throughout the system. The slab movable objects patch set posted by Tobin Harding is an attempt to improve this situation by making it possible for the kernel to actively defragment slab pages by moving objects around.
Over the course of normal operation, the kernel allocates (and sometimes frees) vast numbers of small objects in memory. The slab allocators are designed to make these allocation operations efficient; they allocate whole pages, then parcel out the smaller objects from there. Sets of pages ("slabs") are set aside for objects of a fixed size, allowing them to be efficiently packed with a minimum of overhead and waste. Linux users can choose between three slab allocators: the original allocator (simply called "slab"), SLUB (the newer allocator used on most systems), and SLOB (a minimal allocator for the smallest systems).

For a window into how the allocator on a given system is working, one can look at /proc/slabinfo. On your editor's system, for example, there are currently 338,860 active dentry cache entries, each of which requires an object from the slab allocator. A dentry structure is 192 bytes on this system, so 21 of them can be allocated from each full page. Thus, a minimum of 16,136 pages are needed to hold these objects; on the system in question, 16,461 are actually used for that purpose. There are thus over 300 pages allocated beyond what is strictly needed, which is actually a relatively low level of overhead; it can get a lot worse.

"Sysctl" is the kernel's mechanism for exposing tunable parameters to user space. Every sysctl knob is presented as a virtual file in a hierarchy under /proc/sys; current values can be queried by reading those files, and a suitably privileged user can change a value by writing to its associated file. What happens, though, when a system administrator would like to limit access to sysctl, even for privileged users? Currently there is no solution to this problem other than blocking access to /proc entirely. That may change, though, if this patch set from Andrey Ignatov makes its way into the mainline.
The use case that Ignatov has in mind is containerized applications that, for one reason or another, are run as root. If /proc is mounted in the namespace of such a container, it can be used to change sysctl knobs for the entire system. A hostile container could take advantage of that ability for any of a number of disruptive ends, including perhaps breaking the security of the system as a whole. While disabling or unmounting /proc would close this hole, it may have other, unwanted effects. This situation leads naturally to the desire to exert finer-grained control over access to /proc/sys.

In recent years, one would expect such control to be provided in the form of a new hook for a BPF program, and one would not be disappointed in this case. The patch set adds a new BPF program type (BPF_PROG_TYPE_CGROUP_SYSCTL) and a new operation in the bpf() system call (BPF_CGROUP_SYSCTL) to install programs of that type. As can be inferred from the names, these programs are attached by way of control groups, so different levels of control can be applied in different parts of the system.

Arguments can be passed to Python functions by position or by keyword—generally both. There are times when API designers may wish to restrict some function parameters to only be passed by position, which is harder than some think it should be in pure Python. That has led to a PEP that is meant to make the situation better, but opponents say it doesn't really do that; it simply replaces one obscure mechanism with another. The PEP was assigned a fairly well-known "BDFL delegate" (former BDFL Guido van Rossum), who has accepted it, presumably for Python 3.8.

Finding ways to put backdoors into various programming-language package repositories (e.g. npm, PyPI, and now RubyGems) seems like it is becoming a new Olympic sport or something. Every time you turn around, there is a report of a new backdoor. It is now apparently Ruby's turn, with a new report of a remote-execution backdoor being inserted, briefly, into a popular gem that is installed by some sites using the Ruby on Rails web-application framework.

The bootstrap-sass gem provides a version of the Bootstrap mobile-centric JavaScript library for Sass environments. It can be easily added to web sites, so it is included in many. As with much of the web-application development today, these kinds of dependencies are often picked up automatically, built into cloud or container images, and deployed into production with little or no human supervision. Unfortunately, bootstrap-sass was backdoored by persons unknown in late March.

The backdoor was discovered quickly, less than a day after the release was made, according to a timeline in a Snyk blog post about the flaw. Version 3.2.0.2 of bootstrap-sass gem was removed from the RubyGems repository, presumably by the malicious actor(s), sometime prior to March 26. That was done to cause users to pick up a new version, 3.2.0.3, that was published on RubyGems on March 26. It contained the backdoor.