Affected: AlmaLinux:9: bpftool, AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core and 52 more

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

Security Fix(es):

* kernel: nftables: nft_set_rbtree skip end interval element from gc (CVE-2024-26581) * kernel: netfilter: nft_limit: reject configurations that cause integer overflow (CVE-2024-26668) * kernel: vfio/pci: Lock external INTx masking ops (CVE-2024-26810) * kernel: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() (CVE-2024-26855) * kernel: x86/xen: Add some null pointer checking to smp.c (CVE-2024-26908) * kernel: netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path (CVE-2024-26925) * kernel: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() (CVE-2024-27020) * kernel: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() (CVE-2024-27019) * kernel: netfilter: flowtable: validate pppoe header (CVE-2024-27016) * kernel: netfilter: bridge: confirm multicast packets before passing them up the stack (CVE-2024-27415) * kernel: netfilter: bridge: replace physindev with physinif in nf_bridge_info (CVE-2024-35839) * kernel: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() (CVE-2024-35898) * kernel: netfilter: nf_tables: discard table flag update with pending basechain deletion (CVE-2024-35897) * kernel: netfilter: validate user input for expected length (CVE-2024-35896) * kernel: netfilter: complete validation of user input (CVE-2024-35962) *…

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

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

nvmet: fix a possible leak when destroy a ctrl during qp establishment

In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.

However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl.

Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.

This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.

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

nvmet: fix a possible leak when destroy a ctrl during qp establishment

In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.

However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl.

Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.

This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.

nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables.

The default behavior when the stack-protector detects an overflow is to terminate your application, resulting…

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: bna: ensure the copied buf is NUL terminated Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user.(CVE-2024-36934) In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential kernel bug due to lack of writeback flag waiting Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (__folio_start_writeback in the log below): kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: <TASK> nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 <…

kernel: x86/xen: Fix memory leak in xen_smp_intr_init{_pv}() kernel: cxl/port: Fix delete_endpoint() vs parent unregistration race kernel: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc kernel: nftables: nft_set_rbtree skip end interval element from gc kernel: netfilter: nft_limit: reject configurations that cause integer overflow kernel: vfio/pci: Lock external INTx masking ops kernel: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() kernel: x86/xen: Add some null pointer checking to smp.c kernel: netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path kernel: netfilter: flowtable: validate pppoe header kernel: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() kernel: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() kernel: netfilter: bridge: confirm multicast packets before passing them up the stack kernel: netfilter: bridge: replace physindev with physinif in nf_bridge_info kernel: netfilter: validate user input for expected length kernel: netfilter: nf_tables: discard table flag update with pending basechain deletion kernel: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() kernel: netfilter: complete validation of user input kernel: ice: fix LAG and VF lock dependency in ice_reset_vf() kernel: scsi: qla2xxx: Fix off by one in qla_edif_app_getstats() kernel: net: bridge: xmit: make sure we have at least eth header len bytes kernel: bnxt_re: avoid shif…

kernel: kyber: fix out of bounds access when preempted kernel: Input: elantech - fix stack out of bound access in elantech_change_report_id() kernel: asix: fix uninit-value in asix_mdio_read() kernel: driver core: auxiliary bus: Fix memory leak when driver_register() fail kernel: ACPI: fix NULL pointer dereference kernel: watchdog: Fix possible use-after-free by calling del_timer_sync() kernel: fbmem: Do not delete the mode that is still in use kernel: virtio-net: Add validation for used length kernel: tty: Fix out-of-bound vmalloc access in imageblit kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: block: don't call rq_qos_ops->done_bio if the bio isn't tracked kernel: lib/generic-radix-tree.c: Don't overflow in peek() kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: ptp: Fix possible memory leak in ptp_clock_register() kernel: mm, slub: fix potential memoryleak in kmem_cache_open() kernel: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells kernel: serial: core: fix transmit-buffer reset and memleak kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: USB: core: Make do_proc_control() and do_proc_bulk() k…

nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables.

The default behavior when the stack-protector detects an overflow is to terminate your application, resulting…

Security update for the Linux Kernel

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 132 more

In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a possible leak when destroy a ctrl during qp establishment In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl. Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that. This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.