CVE-2024-50217

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()

Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details:

1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV):

         /  btrfs_device_1 → loop0
   

   fs_device \ btrfs_device_2 → loop1

2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file)

3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF !

Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 → loop0 fs_device \ btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: bpf: support non-r10 register spill/fill to/from stack in precision tracking Use instruction (jump) history to record instructions that performed register spill/fill to/from stack, regardless if this was done through read-only r10 register, or any other register after copying r10 into it and potentially adjusting offset. To make this work reliably, we push extra per-instruction flags into instruction history, encoding stack slot index (spi) and stack frame number in extra 10 bit flags we take away from prev_idx in instruction history. We don't touch idx field for maximum performance, as it's checked most frequently during backtracking. This change removes basically the last remaining practical limitation of precision backtracking logic in BPF verifier. It fixes known deficiencies, but also opens up new opportunities to reduce number of verified states, explored in the subsequent patches. There are only three differences in selftests' BPF object files according to veristat, all in the positive direction (less states). File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) -------------------------------------- ------------- --------- --------- ------------- ---------- ---------- ------------- test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%) xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%) xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%) Note, I avoided renaming jmp_history to more generic insn_hist to minimize number of lines changed and potential merge conflicts between bpf and bpf-next trees. Notice also cur_hist_entry pointer reset to NULL at the beginning of instruction verification loop. This pointer avoids the problem of relying on last jump history entry's insn_idx to determine whether we already have entry for current instruction or not. It can happen that we added jump history entry because current instruction is_jmp_point(), but also we need to add instruction flags for stack access. In this case, we don't want to entries, so we need to reuse last added entry, if it is present. Relying on insn_idx comparison has the same ambiguity problem as the one that was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/(CVE-2023-52920)

In the Linux kernel, the following vulnerability has been resolved:

mptcp: pm: only mark 'subflow' endp as available

Adding the following warning ...

WARN_ON_ONCE(msk->pm.local_addr_used == 0)

... before decrementing the local_addr_used counter helped to find a bug when running the "remove single address" subtest from the mptcp_join.sh selftests.

Removing a 'signal' endpoint will trigger the removal of all subflows linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used counter, which is wrong in this case because this counter is linked to 'subflow' endpoints, and here it is a 'signal' endpoint that is being removed.

Now, the counter is decremented, only if the ID is being used outside of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and if the ID is not 0 -- local_addr_used is not taking into account these ones. This marking of the ID as being available, and the decrement is done no matter if a subflow using this ID is currently available, because the subflow could have been closed before.(CVE-2024-45010)

In the Linux…

Root has patched CVE-2024-50217 in the linux package for Root:Debian:11. Multiple fixed versions available.

Root has patched CVE-2024-50217 in the linux package for Root:Debian:12. Multiple fixed versions available.

Root has patched CVE-2024-50217 in the linux package for Root:Ubuntu:22.04. Multiple fixed versions available.

Root has patched CVE-2024-50217 in the linux package for Root:Ubuntu:24.04. Multiple fixed versions available.

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 → loop0 fs_device \ btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().

These are all security issues fixed in the kernel-devel-6.11.8-1.1 package on the GA media of openSUSE Tumbleweed.

These are all security issues fixed in the kernel-devel-longterm-6.12.11-1.1 package on the GA media of openSUSE Tumbleweed.

Attila Szász discovered that the HFS+ file system implementation in the Linux Kernel contained a heap overflow vulnerability. An attacker could use a specially crafted file system image that, when mounted, could cause a denial of service (system crash) or possibly execute arbitrary code. (CVE-2025-0927)

Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems:

• ARM32 architecture;
• ARM64 architecture;
• PowerPC architecture;
• RISC-V architecture;
• S390 architecture;
• SuperH RISC architecture;
• User-Mode Linux (UML);
• x86 architecture;
• Block layer subsystem;
• Cryptographic API;
• Compute Acceleration Framework;
• ACPI drivers;
• Drivers core;
• ATA over ethernet (AOE) driver;
• RAM backed block device driver;
• Network block device driver;
• Ublk userspace block driver;
• Compressed RAM block device driver;
• Bluetooth drivers;
• TPM device driver;
• Clock framework and drivers;
• Data acquisition framework and drivers;
• CPU frequency scaling framework;
• Hardware crypto device drivers;
• CXL (Compute Express Link) drivers;
• DAX dirext access to differentiated memory framework;
• Buffer Sharing and Synchronization framework;
• EDAC drivers;
• FireWire subsystem;
• ARM SCMI message protocol;
• ARM SCPI message protocol;
• EFI core;
• Qualcomm firmware drivers;
• GPIO subsystem;
• GPU drivers;
• HID subsystem;
• I2C subsystem;
• I3C subsystem;
• IIO ADC drivers;
• IIO subsystem;
• InfiniBand drivers;
• Input Device core drivers;
• IOMMU subsystem;
• IRQ chip drivers;
• Mailbox framework;
• Multiple devices driver;
• Media drivers;
• Multifunction device drivers;
• MMC subsystem;
• MTD block device drivers;
• Ethernet bonding driver;
• Network drivers;
• Mellanox network drivers;
• STMicroelectronics network drivers;
• NTB driver;
• Virtio pmem driver;
• NVME drivers;
• Parport drivers;
• PCI subsystem;
• Alibaba DDR Sub-System Driveway PMU driver;
• PHY drivers;
• Pin controllers subsystem;
• x86 platform drivers;
• i.MX PM domains;
• Powercap sysfs driver;
• Voltage and Current Regulator drivers;
• Remote Processor subsystem;
• StarFive reset controller drivers;
• Real Time Clock drivers;
• SCSI subsystem;
• SuperH / SH-Mobile drivers;
• QCOM SoC drivers;
• Xilinx SoC drivers;
• SPI subsystem;
• Direct Digital Synthesis drivers;
• Media staging drivers;
• TCM subsystem;
• Thermal drivers;
• Thunderbolt and USB4 drivers;
• TTY drivers;
• UFS subsystem;
• USB Device Class drivers;
• DesignWare USB3 driver;
• USB Gadget drivers;
• USB Host Controller drivers;
• USB Dual Role (OTG-ready) Controller drivers;
• USB Serial drivers;
• USB Type-C support driver;
• USB Type-C Port Controller Manager driver;
• TI TPS6598x USB Power Delivery controller driver;
• USB Type-C Connector System Software Interface driver;
• vDPA drivers;
• VFIO drivers;
• Virtio Host (VHOST) subsystem;
• Framebuffer layer;
• Virtio drivers;
• Xen hypervisor drivers;
• AFS file system;
• BTRFS file system;
• File systems infrastructure;
• Ceph distributed file system;
• EROFS file system;
• Ext4 file system;
• F2FS file system;
• GFS2 file system;
• JFS file system;
• Network file systems library;
• Network file system (NFS) client;
• Network file system (NFS) server daemon;
• NILFS2 file system;
• File system notification infrastructure;
• NTFS3 file system;
• Proc file system;
• SMB network file system;
• UBI file system;
• BPF subsystem;
• Network file system (NFS) superblock;
• Virtio network driver;
• Bluetooth subsystem;
• Network traffic control;
• Network sockets;
• TCP network protocol;
• Tracing infrastructure;
• User-space API (UAPI);
• Kernel init infrastructure; -…

It was discovered that some Arm processors could complete a broadcast translation lookaside buffer (TLB) invalidation before memory writes made through the invalidated translation were globally observed. A local attacker could possibly use this to write to memory after permission to do so had been revoked, bypassing memory protections or escalating privileges. (CVE-2025-10263)

Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems:

• ARM64 architecture;
• User-space API (UAPI);
• Kernel build system;
• ARM32 architecture;
• PowerPC architecture;
• RISC-V architecture;
• S390 architecture;
• User-Mode Linux (UML);
• x86 architecture;
• Cryptographic API;
• Intel NPU Driver;
• Compute Acceleration Framework;
• ACPI drivers;
• Drivers core;
• DRBD Distributed Replicated Block Device drivers;
• Rados block device (RBD) driver;
• Ublk userspace block driver;
• Compressed RAM block device driver;
• Bluetooth drivers;
• Hardware crypto device drivers;
• CXL (Compute Express Link) drivers;
• Arm Firmware Framework for ARMv8-A(FFA);
• EFI core;
• FPGA Framework;
• GPU drivers;
• HID subsystem;
• Hardware monitoring drivers;
• I2C subsystem;
• I3C subsystem;
• InfiniBand drivers;
• Input Device core drivers;
• Input Device (Mouse) drivers;
• IOMMU subsystem;
• Multiple devices driver;
• Media drivers;
• Fastrpc Driver;
• Network drivers;
• Mellanox network drivers;
• Microsoft Azure Network Adapter (MANA) driver;
• MediaTek network drivers;
• NVME drivers;
• Operating Performance Points (OPP) driver;
• PCI subsystem;
• PTP clock framework;
• RPMSG subsystem;
• SCSI subsystem;
• SoundWire subsystem;
• SPI subsystem;
• Greybus lights staging drivers;
• Media staging drivers;
• NVIDIA Tegra embedded controller (NVEC) staging driver;
• Realtek RTL8723BS SDIO drivers;
• TCM subsystem;
• Trusted Execution Environment drivers;
• Thunderbolt and USB4 drivers;
• TTY drivers;
• USB Gadget drivers;
• USB Dual Role (OTG-ready) Controller drivers;
• USB Serial drivers;
• vDPA drivers;
• VFIO drivers;
• Virtio Host (VHOST) subsystem;
• Virtio drivers;
• Xen hypervisor drivers;
• 9P distributed file system;
• AFS file system;
• File systems infrastructure;
• BTRFS file system;
• Ceph distributed file system;
• exFAT file system;
• F2FS file system;
• GFS2 file system;
• HFS file system;
• HFS+ file system;
• JFS file system;
• Network file systems library;
• Network file system (NFS) client;
• Network file system (NFS) server daemon;
• NTFS3 file system;
• OCFS2 file system;
• OrangeFS file system;
• SMB network file system;
• BPF subsystem;
• File system encryption (fscrypt);
• Software nodes and device properties;
• IPv4 networking;
• KVM subsystem;
• Mellanox drivers;
• Memory management;
• Networking core;
• Netfilter;
• Socket messages infrastructure;
• MediaTek SoC drivers;
• Sun RPC protocol;
• Network traffic control;
• IPv6 networking;
• Amateur Radio drivers;
• Bluetooth subsystem;
• IP tunnels definitions;
• KCM (Kernel Connection Multiplexor) sockets driver;
• MultiProtocol Label Switching driver;
• TCP network protocol;
• XFRM subsystem;
• Tracing infrastructure;
• io_uring subsystem;
• Control group (cgroup);
• Perf events;
• IRQ subsystem;
• Locking primitives;
• KProbes tracing;
• 9P file system network protocol;
• B.A.T.M.A.N. meshing protocol;
• Ethernet bridge;
• CAN network layer;
• Ceph Core library;
• Handshake API;
• HSR network protocol;
• IFE protocol;
• L2TP protocol;
• MAC80211 subsystem;
• IEEE 802.15.4 subsystem;
• Multipath TCP;
• NFC subsystem;
• Open vSwitch;
• Phonet protocol;
• RDS protocol;
• RxRPC session sockets;
• SCTP protocol;
• SMC…