Affected: AlmaLinux:10: kernel, AlmaLinux:10: kernel-64k, AlmaLinux:10: kernel-64k-core, AlmaLinux:10: kernel-64k-debug, AlmaLinux:10: kernel-64k-debug-core, AlmaLinux:10: kernel-64k-debug-devel, AlmaLinux:10: kernel-64k-debug-devel-matched, AlmaLinux:10: kernel-64k-debug-modules, AlmaLinux:10: kernel-64k-debug-modules-core, AlmaLinux:10: kernel-64k-debug-modules-extra and 65 more

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: xen: Xen hypercall page unsafe against speculative attacks (Xen Security Advisory 466) (CVE-2024-53241) * kernel: exfat: fix out-of-bounds access of directory entries (CVE-2024-53147) * kernel: zram: fix NULL pointer in comp_algorithm_show() (CVE-2024-53222) * kernel: nfsd: release svc_expkey/svc_export with rcu_work (CVE-2024-53216) * kernel: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl (CVE-2024-56662) * kernel: bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors (CVE-2024-56675) * kernel: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY (CVE-2024-56690) * kernel: igb: Fix potential invalid memory access in igb_init_module() (CVE-2024-52332) * kernel: af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK (CVE-2024-57901) * kernel: af_packet: fix vlan_get_tci() vs MSG_PEEK (CVE-2024-57902) * kernel: io_uring/sqpoll: zero sqd->thread on tctx errors (CVE-2025-21633) * kernel: ipvlan: Fix use-after-free in ipvlan_get_iflink(). (CVE-2025-21652) * kernel: sched: sch_cake: add bounds checks to host bulk flow fairness counts (CVE-2025-21647) * kernel: io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period (CVE-2025-21655) * kernel: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled (CVE-2024-57941) * kernel: netfs: Fix ceph copy to cache…

Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

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

ata: libata-sff: Ensure that we cannot write outside the allocated buffer

reveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len set to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to ATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to write outside the allocated buffer, overwriting random memory.

While a ATA device is supposed to abort a ATA_NOP command, there does seem to be a bug either in libata-sff or QEMU, where either this status is not set, or the status is cleared before read by ata_sff_hsm_move(). Anyway, that is most likely a separate bug.

Looking at __atapi_pio_bytes(), it already has a safety check to ensure that __atapi_pio_bytes() cannot write outside the allocated buffer.

Add a similar check to ata_pio_sector(), such that also ata_pio_sector() cannot write outside the allocated buffer.

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

ata: libata-sff: Ensure that we cannot write outside the allocated buffer

reveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len set to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to ATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to write outside the allocated buffer, overwriting random memory.

While a ATA device is supposed to abort a ATA_NOP command, there does seem to be a bug either in libata-sff or QEMU, where either this status is not set, or the status is cleared before read by ata_sff_hsm_move(). Anyway, that is most likely a separate bug.

Looking at __atapi_pio_bytes(), it already has a safety check to ensure that __atapi_pio_bytes() cannot write outside the allocated buffer.

Add a similar check to ata_pio_sector(), such that also ata_pio_sector() cannot write outside the allocated buffer.

Affected: openEuler:24.03-LTS: kernel

The Linux Kernel, the operating system core itself. Security Fix(es):

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

fs: relax assertions on failure to encode file handles

Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons.

The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.

There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong.

The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate.

The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.

Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlayfs that is mounted with options index=on,nfs_export=on also on kernels < v6.6. Therefore, I am not listing the aforementioned commit as a Fixes commit.

Backport hint: this patch will have a trivial conflict applying to v6.6.y, and other trivial conflicts applying to stable kernels &l…

microcode_ctl: From CVEorg collector kernel: information leak via transient execution vulnerability in some AMD processors kernel: transient execution vulnerability in some AMD processors kernel: drm/xe/tracing: Fix a potential TP_printk UAF kernel: igb: Fix potential invalid memory access in igb_init_module() kernel: exfat: fix out-of-bounds access of directory entries kernel: nfsd: release svc_expkey/svc_export with rcu_work kernel: zram: fix NULL pointer in comp_algorithm_show() kernel: xen: Xen hypercall page unsafe against speculative attacks (Xen Security Advisory 466) kernel: NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client() kernel: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl kernel: bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors kernel: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY kernel: af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK kernel: af_packet: fix vlan_get_tci() vs MSG_PEEK kernel: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled kernel: netfs: Fix ceph copy to cache on write-begin kernel: memcg: fix soft lockup in the OOM process kernel: usb: xhci: Fix NULL pointer dereference on certain command aborts kernel: xfrm: state: fix out-of-bounds read during lookup kernel: i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition kernel: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections kernel: Bluet…

Security update for the Linux Kernel

Affected: Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 198 more

In the Linux kernel, the following vulnerability has been resolved: ata: libata-sff: Ensure that we cannot write outside the allocated buffer reveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len set to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to ATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to write outside the allocated buffer, overwriting random memory. While a ATA device is supposed to abort a ATA_NOP command, there does seem to be a bug either in libata-sff or QEMU, where either this status is not set, or the status is cleared before read by ata_sff_hsm_move(). Anyway, that is most likely a separate bug. Looking at __atapi_pio_bytes(), it already has a safety check to ensure that __atapi_pio_bytes() cannot write outside the allocated buffer. Add a similar check to ata_pio_sector(), such that also ata_pio_sector() cannot write outside the allocated buffer.

Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um die Vertraulichkeit, Integrität und Verfügbarkeit zu gefährden.