MantisBT - Issues

0000644: AlmaLinux 10: advisories removed from errata.full.json while their HTML pages remain published — which source is authoritative?

Fri, 03 Jul 2026 01:45:49 +0000

I help maintain the data pipeline of an open-source vulnerability scanner
https://github.com/future-architect/vuls/ , which consumes https://errata.almalinux.org/10/errata.full.json.

Around 2026-05-19..26, the AlmaLinux 10 errata feed went through a large
re-curation:

- Many published ALSA advisories disappeared from errata.full.json.
Our snapshot of 2026-05-21 contained 279 advisories; during that window
the feed shrank to roughly 60, and it has since regrown to 264
(as of 2026-07-02).
- Some advisories were re-issued under new IDs, in some cases more than
once. Example: CVE-2025-13601 was covered by ALSA-2026:0975, which
disappeared and is now covered by ALSA-2026:18344.
- However, the static HTML pages of the removed advisories are still
published: they return HTTP 200 with full content, and they are still
listed in the directory index at https://errata.almalinux.org/10/
(504 ALSA-*.html files vs 264 entries in the current feed).

Impact: comparing our 2026-05-21 snapshot with the current feed, the
removed advisories referenced 434 unique CVEs, of which only 58 are still
referenced by any advisory in the current feed. The remaining 376 CVEs are
no longer covered at all. For downstream consumers of the feed (security
scanners, SBOM/VEX tooling), this is an effective loss of detection
coverage for AlmaLinux 10, while the same advisories still look
"published" on the website.

Questions:
1. Was the removal of these advisories from errata.full.json an
intentional retirement/re-curation, or a side effect of how the feed
is regenerated?
2. Which source should downstream consumers treat as authoritative:
errata.full.json, the HTML pages, or the updateinfo.xml shipped in
the repositories?
3. If the retirement is intentional, could the corresponding HTML pages
be removed or marked as retired, so the two sources stay consistent?
Conversely, if it is not intentional, could the feed be regenerated
to include them again?
4. Is there any announcement or changelog describing this re-curation
that we could reference?

Other examples absent from the feed but live as HTML:
- https://errata.almalinux.org/10/ALSA-2025-21013.html (libssh)
- https://errata.almalinux.org/10/ALSA-2025-23479.html (openssh)
- https://errata.almalinux.org/10/ALSA-2026-13515.html (freeipmi)
- https://errata.almalinux.org/10/ALSA-2026-3517.html (thunderbird)

0000638: samba-4.19.4-16.el8_10.src.rpm fails to build on AlmaLinux 8.10: samba-4.19-redhat.patch cannot be applied

Thu, 02 Jul 2026 08:11:05 +0000

I am trying to rebuild the official samba-4.19.4-16.el8_10.src.rpm package on AlmaLinux 8.10.

The build process fails during the %prep phase while applying the samba-4.19-redhat.patch patch.

The error obtained is:

/usr/bin/patch -p1 -s --fuzz=0 --no-backup-if-mismatch

1 out of 3 hunks FAILED -- saving rejects to file lib/util/substitute.c.rej
1 out of 7 hunks FAILED -- saving rejects to file source3/printing/print_generic.c.rej
1 out of 1 hunk FAILED -- saving rejects to file docs-xml/smbdotconf/printing/printcommand.xml.rej

error: Bad exit status from /var/tmp/rpm-tmp.ulMvkp (%prep)

0000643: [AlmaLinux][Backport][MANA] net: mana: Fall back to standard MTU when PF reports adapter_mtu of 0

Wed, 01 Jul 2026 17:10:13 +0000

Request backport of the following bug fix patch.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=6bd81a5b4e0d

0000642: [AlmaLinux][Mana][Backport] net: mana: Fix crash from unvalidated SHM offset read from BAR0 during FLR

Wed, 01 Jul 2026 14:31:42 +0000

Request backport of the following patch.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=95084f1883a7

0000641: [AlmaLinux][Backport][Mana] patches for Numa, RSS Queues.

Wed, 01 Jul 2026 14:25:23 +0000

Request backport of the following patches

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=45b2b84ac6fde39c427018d6cdf7d44258938faa
https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/commit/?h=hyperv-fixes&id=7b3b1e5a87b2f5e35c52b5386d7c327be869454f

0000640: [AlmaLinux][Backport][MANA] net: mana: Optimize irq affinity for low vcpu configs

Wed, 01 Jul 2026 13:59:06 +0000

Upstream References

https://lore.kernel.org/all/20260624072138.1632849-1-shradhagupta@linux.microsoft.com/

Dependence Patch
upstream previous kernel version for patch: bug fix for: Fixes: 755391121038 ("net: mana: Allocate MSI-X vectors dynamically")

0000639: [AlmaLinux][Backport][MANA] net: mana: fix error-path issues in queue setup

Tue, 30 Jun 2026 12:55:57 +0000

Request backport of the following patch.

Problem Summary
Two error-path fixes in MANA queue setup, both surfaced during review of a recently upstreamed patch series.

Patch 1 initializes queue->id to INVALID_QUEUE_ID in mana_gd_create_mana_wq_cq() so that a CQ creation failure before the firmware id is assigned does not NULL gc->cq_table[0] and silently break whichever real CQ owns that slot. This mirrors the existing pattern in mana_gd_create_eq().

Patch 2 guards mana_destroy_txq()'s call to mana_destroy_wq_obj() with an INVALID_MANA_HANDLE check, mirroring mana_destroy_rxq(). Without it, TX setup failures lead to a firmware-rejected destroy of (u64)-1 and a spurious error in dmesg.

Upstream reference

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=5985474e1cb4
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f8fd56977eee

0000637: [AlmaLinux][Mana][Backport] Cobalt 200 mana networking performance patch to use full 4k page rx buffers (disable page fragmentat

Tue, 30 Jun 2026 12:18:05 +0000

Request backport of the following patch.

Primary Patch

https://lore.kernel.org/all/20260602202801.1873742-1-dipayanroy@linux.microsoft.com/

Prerequisite Patches
https://lore.kernel.org/all/acLUhLpLum6qrD%2fN@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net/
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=17bfe0a8c014
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=5b05aa36ee24

Dependencies
All prerequisite patches must be applied before enabling the ethtool flag patch
Requires existing MANA RX path implementation with page_pool support

0000636: kernel BUG in folio_end_writeback via cifs_writepages on close()

Fri, 26 Jun 2026 11:21:08 +0000

--------------------------------------------------------------------------------
SUMMARY
--------------------------------------------------------------------------------

5.14.0-687.15.1.el9_8 — kernel BUG at mm/filemap.c:1593 in folio_end_writeback,
reached from cifs_writepages during the writeback flush on close(). Seen in the
same event are a refcount_warn_saturate (refcount underflow / use-after-free) in
the CIFS async write path and a socket send failure (Error -32 / EPIPE) to the
server. The crash(8) disassembly confirms the BUG is the
"if (!__folio_end_writeback(folio)) BUG();" case — i.e. writeback is ended on a
folio whose writeback flag was already clear (a double-completion of writeback).

Severity: crash / kernel panic
Category: kernel

--------------------------------------------------------------------------------
TWO INDEPENDENT MACHINES, IDENTICAL PANIC
--------------------------------------------------------------------------------

The same panic was captured on two physically different servers running the
identical kernel build. The call traces match down to the same symbol offsets.

hostA
Server : Dell PowerEdge R740, BIOS 2.26.1
Kernel : 5.14.0-687.15.1.el9_8
Comm : dask worker [tc (PID 70950, CPU 22)
Hardware: 40 CPUs, 766.6 GB RAM
CIFS : cache=none

hostB
Server : Dell PowerEdge R750xa, BIOS 1.20.2
Kernel : 5.14.0-687.15.1.el9_8
Comm : pt_main_thread (PID 246362, CPU 21)
Hardware: 24 CPUs, 383.2 GB RAM
CIFS : cache=strict

Kernel build string (both dumps):

Linux version 5.14.0-687.15.1.el9_8.x86_64
(mockbuild@x64-builder01.almalinux.org) ...
#1 SMP PREEMPT_DYNAMIC Thu Jun 11 08:51:45 EDT 2026

Two different server models crashing at the identical instruction with the
identical call chain points to a software defect, not a per-machine hardware
fault. The only taint flag present before the crash is from an out-of-tree
module (NVIDIA, visible in "Modules linked in"); there is no machine-check /
hardware-error taint in either dump.

The two hosts also run different CIFS cache modes (hostA cache=none, hostB
cache=strict) yet hit the identical signature — see "Both cache modes affected"
below.

--------------------------------------------------------------------------------
WHAT THE DUMPS SHOW
--------------------------------------------------------------------------------

In both dumps the crash is a two-part event on the same CPU/PID. The two parts
are shown below in the order the report discusses them; the order in which they
were actually printed to the kernel log varies (see "A note on ordering" at the
end of this section).

1) refcount underflow in the CIFS async write path

refcount_t: underflow; use-after-free.
WARNING: CPU: PID: at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
... Tainted: P OE 5.14.0-687.15.1.el9_8.x86_64
Hardware name: Dell Inc. PowerEdge R740, BIOS 2.26.1
RIP: 0010:refcount_warn_saturate+0xba/0x110
Call Trace:
refcount_warn_saturate+0xba/0x110
cifs_call_async+0x1ee/0x330 [cifs]
smb2_async_writev+0x473/0x6f0 [cifs]
? __pfx_cifs_writedata_release+0x10/0x10 [cifs]
cifs_writepages+0x52f/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
cifs_flush+0x73/0x120 [cifs]
__x64_sys_close+0x2e/0x80

The release function on the stack is cifs_writedata_release — i.e. the object
whose refcount saturates/underflows is the CIFS writedata associated with this
writeback.

2) socket send failure, and the BUG

CIFS: VFS: \\ Error -32 sending data on socket to server
------------[ cut here ]------------
kernel BUG at mm/filemap.c:1593!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
... Tainted: P W OE 5.14.0-687.15.1.el9_8.x86_64
Hardware name: Dell Inc. PowerEdge R740, BIOS 2.26.1
RIP: 0010:folio_end_writeback+0x7d/0x80
Call Trace:
folio_end_writeback+0x7d/0x80
cifs_writepages+0x998/0xbc0 [cifs]
do_writepages+0xd5/0x1b0
filemap_fdatawrite_wbc+0x66/0x90
filemap_write_and_wait_range+0x3e/0xb0
cifs_flush+0x73/0x120 [cifs]
__x64_sys_close+0x2e/0x80

BUG at mm/filemap.c:1593 inside folio_end_writeback means writeback is being
ended on a folio that is no longer flagged as under writeback — the folio's
writeback state has already been completed/torn down once. Combined with the
refcount underflow on the CIFS writedata and the socket send failure
(Error -32 / EPIPE) seen in the same event, the signature is a use-after-free
/ double-completion of the writeback in the SMB2 async write path, occurring
during the flush on close(). We read the failed/aborted send during writeback
as the likely trigger, but state this as a hypothesis rather than a proven
sequence (see "A note on ordering").

Matching offsets on both machines: cifs_call_async+0x1ee, smb2_async_writev+0x473,
cifs_writepages+0x52f (send path) and +0x998 (writeback-end path),
folio_end_writeback+0x7d, BUG at mm/filemap.c:1593.

A note on ordering

The three symptoms — the refcount underflow (refcount_warn_saturate), the
socket send failure (CIFS: VFS: ... Error -32 sending data on socket), and the
BUG in folio_end_writeback — appear together in every dump, but their PRINTED
order is not stable (it differs between hosts and even between different dumps
of the same host). We therefore do NOT claim a proven cause-and-effect order
between the send failure and the refcount underflow. printk ordering on a
many-CPU box under load does not necessarily reflect the true event timeline,
and the send-error and refcount messages originate in different contexts. What
is consistent across both dumps is the end state: a CIFS writeback whose state
is ended twice (__folio_end_writeback() returns false -> BUG), in the close()
flush path, in the presence of a failing/aborted SMB2 send. The "failed send
during writeback triggers a bad writeback completion" reading is our
best-supported hypothesis, not a fact the logs establish on their own.

--------------------------------------------------------------------------------
BOTH CACHE MODES AFFECTED
--------------------------------------------------------------------------------

The two hosts run different CIFS cache modes, and each crashed with the same
confirmed signature:

- hostA (R740): cache=none
- hostB (R750xa): cache=strict

This is visible in the stacks themselves. On hostB (cache=strict), the writeback
path goes through cifs_strict_writev:

cifs_writepages+0x52f/0xbc0 [cifs]
? generic_perform_write+0x14c/0x210
do_writepages+0xd5/0x1b0
? cifs_strict_writev+0x1c4/0x330 [cifs] <-- strict path
...
cifs_writepages+0x998/0xbc0 [cifs]
? cifs_strict_writev+0x1c4/0x330 [cifs] <-- strict path
do_writepages+0xd5/0x1b0
cifs_flush+0x73/0x120 [cifs]

The cifs_strict_writev frame is present on hostB and absent on hostA, confirming
the two crashes reach the same folio_end_writeback double-completion through two
different CIFS write paths (strict vs. none). The bug therefore does NOT depend
on a single cache mode; it is in the writeback-completion handling common to
both.

--------------------------------------------------------------------------------
crash(8) ANALYSIS — VERIFIED SOURCE LINE AND FULL KERNEL STACK
--------------------------------------------------------------------------------

crash(8) sessions over the full vmcores (with vmlinux debuginfo for
5.14.0-687.15.1.el9_8) confirm the source line and the complete in-kernel stack
that the redacted dmesg only shows by offset.

The disassembly of folio_end_writeback shows the BUG() at line 1593 is reached
directly from the "if (!__folio_end_writeback(folio)) BUG();" path — i.e.
__folio_end_writeback() returned false because the folio's PG_writeback flag was
already clear:

1591 folio_get(folio);
1592 if (!__folio_end_writeback(folio))
... call __folio_end_writeback ; test %al,%al ; je <+125>
1593 BUG();
0xffffffff8137921d <+125>: ud2

Resolved kernel-side backtrace (hostA; hostB is identical bar addresses):

[exception RIP: folio_end_writeback+125]
0000008 cifs_writepages [cifs]
0000009 do_writepages
0000010 filemap_fdatawrite_wbc
0000011 __filemap_fdatawrite_range
0000012 filemap_write_and_wait_range
#13 cifs_flush [cifs]
0000014 filp_flush
0000015 __x64_sys_close
0000016 do_syscall_64
0000017 entry_SYSCALL_64_after_hwframe

This matches the dmesg-derived signature exactly and pins the BUG to the
__folio_end_writeback()-returns-false (writeback already ended) case.

Note for reviewers: in the slab PAGE lines of the attachments, MAPPING values
of the form dead0000000004xx / dead000000000001 are the normal kernel slab
page-poison marker (page->mapping for a slab page), NOT corruption and NOT a
redaction.

--------------------------------------------------------------------------------
CIFS MOUNT OPTIONS (anonymized)
--------------------------------------------------------------------------------

Requested options (autofs map; same on both hosts):

sec=krb5,cruid=${UID},uid=${UID},gid=${GID},forceuid,forcegid,
iocharset=utf8,vers=3.0,nosuid,nodev,dir_mode=0700,file_mode=0700,
noserverino,cache=none

Effective options after expansion (from the dumps), anonymized:

hostA (R740) — cache=none:

rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=,cache=none,
upcall_target=app,username=,uid=,forceuid,gid=,
forcegid,addr=,file_mode=0700,dir_mode=0700,
iocharset=utf8,soft,nounix,mapposix,reparse=nfs,nativesocket,
symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,
echo_interval=60,actimeo=1,closetimeo=1

hostB (R750xa) — cache=strict:

rw,nosuid,nodev,relatime,vers=3.0,sec=krb5,cruid=,cache=strict,
upcall_target=app,username=,uid=,forceuid,gid=,
forcegid,addr=,file_mode=0700,dir_mode=0700,
iocharset=utf8,soft,nounix,mapposix,reparse=nfs,nativesocket,
symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,
echo_interval=60,actimeo=1,closetimeo=1

Anonymized fields: cruid/uid -> , gid -> , username -> ,
addr -> . All other values are verbatim. The two hosts differ
only in the cache mode (none vs. strict).

Why these may matter to maintainers (context, not a diagnosis):

- cache mode. Same signature under cache=none (hostA) and cache=strict (hostB),
so the bug is not specific to one writeback path; see "Both cache modes
affected".
- vers=3.0 (not 3.1.1) and sec=krb5 narrow down which SMB2/3 code path and
auth path are in use.
- soft, actimeo=1, closetimeo=1. A soft mount with very short attribute/close
timeouts means operations abort with errors sooner under network pressure —
consistent with the Error -32 / "send fails mid-writeback" condition seen in
the dumps.
- rsize/wsize=4194304 (4 MiB). Large I/O sizes, relevant to how writeback is
chunked.

We note these as potentially relevant context; we are not claiming any single
option is the proven cause.

--------------------------------------------------------------------------------
UPSTREAM CONTEXT (known class of bug; exact fix status for el9 is an open
question)
--------------------------------------------------------------------------------

This is consistent with a previously reported class of CIFS writeback-completion
bugs rather than a brand-new defect:

- On the linux-cifs list (Feb 2024), Steve French reported the same call path
(cifs_flush -> filemap_write_and_wait_range -> ... -> folio_end_writeback)
hit under xfstests when writes time out due to repeatedly failing server
reconnects. Matthew Wilcox's reading was that the bug is something failing to
call folio_end_writeback() when it should — i.e. a mismatch in writeback-end
accounting, which is exactly the __folio_end_writeback()-returns-false
signature seen here. Our trigger (Error -32 / EPIPE on the socket send during
the close() flush) is the same "send/reconnect fails mid-writeback" condition.
Thread: https://www.spinics.net/lists/linux-cifs/msg31067.html

- The CIFS writeback path saw significant churn upstream: a two-phase
cifs_writepages_begin / cifs_extend_writeback design (around f3dc1bdb6b0b
"cifs: Fix writeback data corruption"), later a cut-over to netfslib
(3ee1a1fc3981), plus follow-up fixes (e.g. a per-cifs_writepages_begin folio
leak fix by Yang Erkun). Several of these touch exactly the folio/writeback
refcounting on the write path.

We have NOT been able to identify a single specific upstream commit and confirm
whether it is present in or missing from 5.14.0-687.15.1.el9_8. Determining
whether el9's backport of the CIFS writeback path already contains the relevant
fix (or needs one) is the key question for the maintainers, and requires checking
the el9 kernel changelog against the upstream CIFS/netfs writeback fixes above.
We're happy to provide the full vmcore(s) and test further.

0000635: AMDI0015 (DesignWare I3C master) driver initialization failure (Timeout -110 / UBSAN shift-out-of-bounds) on AMD EPYC 5th Gen

Thu, 25 Jun 2026 12:58:53 +0000

IMPORTANT NOTE FOR TRIAGE:
We are opening this ticket here under the explicit direction of Benny (AlmaLinux). Although the attached logs were captured from a Proxmox VE kernel environment, this is a critical upstream Linux kernel driver/hardware compatibility issue on the new AMD EPYC 5th Gen platform. It directly impacts any modern enterprise Linux ecosystem trying to leverage native I3C telemetry on this Gigabyte hardware.

---

A critical issue has been identified during the initialization of the native MIPI I3C bus on an AMD EPYC 5th Generation platform hosted on a Gigabyte server (Model: XV23-ZU0-AAJ1-000).

During the boot sequence, the Synopsys/DesignWare I3C master control driver (dw-i3c-master.c) fails entirely. This driver failure triggers two explicit kernel errors:
1. UBSAN Math Error (Underflow): A shift-out-of-bounds error occurs when the driver tries to parse an invalid or corrupt hardware initialization response as an unsigned 64-bit integer.
2. Driver Timeout (Error -110): The integrated AMD ACPI I3C devices (AMDI0015) do not respond to the OS probing requests within the time limit (ETIMEDOUT), causing the controller to fail and disable itself.

Secondary Impact (Power Capping):
Concurrently, the CPU performance is degraded; the processor persistently caps its power consumption at ~245W despite its nominal 300W TDP specification. This is highly suspected to be a security Power Capping mechanism triggered by the AMD System Management Unit (SMU) or BMC due to the lack of high-speed telemetry from the VRMs/PMICs over the failed I3C bus.

Hardware & Firmware Context:
* Server Model: Gigabyte XV23-ZU0-AAJ1-000 (Motherboard MZU3-MG0-000)
* CPU: AMD EPYC 5th Generation
* Firmware: BIOS version R22_F17

0000634: Disk I/O issue in Proxmox VM (Aborted Command) + XFS shut down

Thu, 18 Jun 2026 10:13:05 +0000

Following this thread : https://forum.proxmox.com/threads/io_uring-on-kernel-7-0-6-2-pve-pve-9-2-3-guest-disk-i-o-errors-eio-filesystem-xfs-shutdown.184360/

I discovered a strange behavior on AlmaLinux 10 inside a Proxmox VM. It appears that kernel 6.12.0-211.22.1.el10_2.x86_64 has issue that triggers a disk failure (see screenshots).

Randomly, the filesystem (XFS) becomes unavailable and I can't do anything more except stop and start the VM again.

I don't know if it's related to the storage architecture on Proxmox but I'm using LUKS + LVM-thin on 2 different hosts that are impacted.

Here is the way I was able to reproduce :

root@zabbix :~$ fio --name=stress-write --ioengine=libaio --iodepth=64 --rw=randwrite \
--bs=4k --direct=1 --size=20G --numjobs=8 --runtime=600 \
--time_based --ramp_time=30 --group_reporting \
--filename=/tmp/fio-test --output-format=normal,json \
--output=fio-result.json
Jobs: 8 (f=0): [/(8)][-.-%][eta 10m:15s]
Jobs: 8 (f=0): [/(8)][-.-%][eta 10m:15s]
Jobs: 8 (f=0): [/(8)][-.-%][eta 10m:14s]
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=20592291840, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=9765498880, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=11389923328, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=10865082368, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=4592693248, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=17240551424, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=10608463872, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=18193764352, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=10405310464, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=18420568064, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=20068622336, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=14732562432, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=19714949120, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=11894398976, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=13342396416, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=18269777920, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=21153767424, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=8210624512, buflen=4096
fio: io_u error on file /tmp/fio-test: Input/output error: write offset=5009162240, buflen=4096

0000633: [AlmaLinux][Backport][MANA] net: mana: Cache MANA_QUERY_LINK_CONFIG result to avoid repeated HWC queries

Mon, 15 Jun 2026 05:50:08 +0000

Request backport of the following patch to all active kernels.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=8e0ffcc926f4

0000632: [AlmaLinux][MANA][Backport][Distros] Patch: net: mana: Add support for PF device 0x00C1

Mon, 15 Jun 2026 05:06:37 +0000

Request backport of the following patch.

Problem Summary : Dual link feature added 2nd PF, that require this patch to support it.

Impact on Customer VMs/BMs : All BM (Bare metal) instances with Dual Link feature. (VR system)
Repro details : without this patch the 2nd PF (device 0x00C1) won't be available.
Relationship to large feature : None
Patch Criticality: Medium (High for Distros on VR system)
Classification : New feature
Upstream reference

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=53a65db20a4f3fe6c01b1f789f9eae6b1244910f

0000623: Request to backport recent GVE patches for Google Cloud overcommited Gen3+ VMs for AlmaLinux 8

Wed, 10 Jun 2026 21:49:37 +0000

Currently, the maximum queue depth supported for gVNIC on overcommited Gen3+ VMs such as N4 is 1K, whereas the maximum queue depth supported on Gen1/Gen2 VMs is 2K. Customers who are migrating their workloads from N2 to N4 have requested higher queue depth support on N4 VMs.

GVE driver changes to support greater than 1K queue depth for overcommitted Gen3+ have been upstreamed to Linux kernel recently:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=a2f19184014f
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=07993df56091

0000621: Request to backport recent GVE patches for Google Cloud overcommited Gen3+ VMs for AlmaLinux 10

Fri, 05 Jun 2026 13:20:21 +0000

0000622: Request to backport recent GVE patches for Google Cloud overcommited Gen3+ VMs for AlmaLinux 9

Thu, 04 Jun 2026 17:48:30 +0000

0000631: [AlmaLinux][RDMA/DPDK] [Backport] mana_ib patch to distro to support RX traffic stop on MANA hotplug events

Thu, 04 Jun 2026 14:13:25 +0000

Request backport of the following patch to all active kernels.

This patch correctly shutdown receive traffic when MANA device is hot plugged from DPDK. Without this patch, the kernel may send interrupts under heavy traffic when MANA is hot removed.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v7.1-rc1&id=dbeb256e8dd87233d891b170c0b32a6466467036

0000630: Downloading ISO's from your server

Tue, 02 Jun 2026 05:19:00 +0000

When downloading ISO files from repo.almalinux.org, the Content-Length header is missing from GET responses.
However doing a HEAD request to the same URL returns it correctly.

Example URL:
https://repo.almalinux.org/almalinux/10/live/x86_64_v2/AlmaLinux-10.2-x86_64_v2-Live-KDE.iso
HEAD returns: Content-Length: 2638260224
GET returns: no Content-Length header
This means download managers cannot show progress, percentage or ETA without using a workaround such as doing a HEAD request first.

0000587: Unable to install perl-DBD-MySQL-4.053 in a MySQL 8.4 (libmysqlclient.so.24)

Tue, 02 Jun 2026 05:18:37 +0000

Unable to install perl-DBD-MySQL-4.053 in a MySQL 8.4 (libmysqlclient.so.24) environment
due to a dependency on libmysqlclient.so.21.

0000629: SSSD install/setup issue due to insufficient permissions and ownership

Fri, 29 May 2026 12:36:33 +0000

Hello,
we're having trouble connecting AlmaLinux 10.2 to an Active Directory using SSSD. Previously we were able to set it up just fine using AlmaLinux 10.1.
The following text describes the issues and how to solve them. However, it would be better if the issues were fixed at the source.
Firstly, sssd doesn't own the paths /var/lib/sss and /var/log/sssd.

# systemctl status sssd
× sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Fri 2026-05-29 11:10:06 UTC; 7min ago
Invocation: cddf4fea77444dab88d80a37de5875f2
Process: 4346 ExecStartPre=/bin/chown -f -R -H root:sssd /etc/sssd (code=exited, status=0/SUCCESS)
Process: 4348 ExecStartPre=/bin/chmod -f -R g+r /etc/sssd (code=exited, status=0/SUCCESS)
Process: 4350 ExecStartPre=/bin/chmod -f g+x /etc/sssd (code=exited, status=0/SUCCESS)
Process: 4352 ExecStartPre=/bin/chmod -f g+x /etc/sssd/conf.d (code=exited, status=0/SUCCESS)
Process: 4354 ExecStartPre=/bin/chmod -f g+x /etc/sssd/pki (code=exited, status=0/SUCCESS)
Process: 4356 ExecStartPre=/bin/sh -c /bin/chown -f -h sssd:sssd /var/lib/sss/db/*.ldb (code=exited, status=1/FAILURE)
Process: 4358 ExecStartPre=/bin/chown -f -R -h sssd:sssd /var/lib/sss/gpo_cache (code=exited, status=0/SUCCESS)
Process: 4360 ExecStartPre=/bin/sh -c /bin/chown -f -h sssd:sssd /var/log/sssd/*.log* (code=exited, status=1/FAILURE)
Process: 4362 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=8)
Main PID: 4362 (code=exited, status=8)
Mem peak: 2.3M
CPU: 49ms

May 29 11:10:06 redacted sssd[4362]: Could not open file [/var/log/sssd/sssd.log]. Error: [13][Permission denied]
May 29 11:10:06 redacted sssd[4362]: Error opening log file, falling back to stderr
May 29 11:10:06 redacted sssd[4362]: [sssd] [main] (0x3f7c0): Started under uid=997 (euid=997) : gid=997 (egid=997) with SECBIT_KEEP_CAPS = 0 and following capabilities:
May 29 11:10:06 redacted sssd[4362]: (nothing)
May 29 11:10:06 redacted sssd[4362]: [sssd] [sss_ini_call_validators] (0x0020): [rule/allowed_sssd_options]: Attribute 'config_file_version' is not allowed in section 'sssd'. Check for typos.
May 29 11:10:06 redacted sssd[4362]: [sssd] [confdb_write_ini] (0x0010): Can't delete old '/var/lib/sss/db/config.ldb'
May 29 11:10:06 redacted sssd[4362]: [sssd] [main] (0x0010): Failed to write config DB: 'Permission denied'
May 29 11:10:06 redacted systemd[1]: sssd.service: Main process exited, code=exited, status=8/n/a
May 29 11:10:06 redacted systemd[1]: sssd.service: Failed with result 'exit-code'.
May 29 11:10:06 redacted systemd[1]: Failed to start sssd.service - System Security Services Daemon.

# ls -la /var/log/sssd
total 4
drwxrwx---. 2 root root 6 Apr 14 00:00 .
drwxr-xr-x. 9 root root 4096 May 29 11:09 ..

# ls -la /var/lib/sss
total 4
drwxrwxr-x. 10 root root 120 May 29 11:09 .
drwxr-xr-x. 27 root root 4096 May 29 11:09 ..
drwxrwx---. 2 root root 6 Apr 14 00:00 db
drwxrwx--x. 2 root root 6 Apr 14 00:00 deskprofile
drwxrwx---. 2 sssd sssd 6 Apr 14 00:00 gpo_cache
drwxrwx---. 2 sssd sssd 6 Apr 14 00:00 keytabs
drwxrwxr-x. 2 root root 6 Apr 14 00:00 mc
drwxrwxr-x. 3 root root 21 May 26 13:48 pipes
drwxrwxr-x. 3 root root 28 May 26 13:48 pubconf
drwxrwx---. 2 root root 6 Apr 14 00:00 secrets

The second issue is that the current file permissions for executables are insufficient, that are required for running sssd.

# ls -la /usr/libexec/sssd/
total 2200
drwxr-xr-x. 2 root root 4096 May 29 11:09 .
drwxr-xr-x. 30 root root 4096 May 29 11:09 ..
-rwxr-xr-x. 1 root root 40608 Apr 14 00:00 gpo_child
-rwxr-x---. 1 root root 140016 Apr 14 00:00 krb5_child
-rwxr-x---. 1 root root 53112 Apr 14 00:00 ldap_child
-rwxr-xr-x. 1 root root 73384 Apr 14 00:00 p11_child
-rwxr-x---. 1 root sssd 32368 Apr 14 00:00 proxy_child
-rwxr-x---. 1 root sssd 32416 Apr 14 00:00 selinux_child
-rwxr-xr-x. 1 root root 186968 Apr 14 00:00 sssd_autofs
-rwxr-xr-x. 1 root root 261800 Apr 14 00:00 sssd_be
-rwxr-xr-x. 1 root root 15840 Apr 14 00:00 sssd_check_socket_activated_responders
-rwxr-xr-x. 1 root root 215640 Apr 14 00:00 sssd_kcm
-rwxr-xr-x. 1 root root 266888 Apr 14 00:00 sssd_nss
-rwxr-xr-x. 1 root root 195056 Apr 14 00:00 sssd_pac
-rwxr-x---. 1 root root 306768 Apr 14 00:00 sssd_pam
-rwxr-xr-x. 1 root root 195176 Apr 14 00:00 sssd_ssh
-rwxr-xr-x. 1 root root 195224 Apr 14 00:00 sssd_sudo
-rwxr-xr-x. 1 root root 15800 Apr 14 00:00 sss_signal

This issue can be resolved by running the three commands below and then restarting the SSSD service.

chown -R sssd:sssd /var/lib/sss
chown sssd:sssd /var/log/sssd
chmod o+rx /usr/libexec/sssd/*

0000628: [AlmaLinux][Mana][Backport] net: mana: Avoid queue struct allocation failure under memory fragmentation

Thu, 28 May 2026 13:06:37 +0000

Backport Justification (ADO)

1. Problem Summary

MANA driver does large contiguous kmallocs during queue setup that may fail in system with highly fragmented memory:

- mana_create_txq (tx_qp array): 0000005:0000002.2 MB @ 64 queues
- mana_create_rxq (rxq + flex array): 0000005:0000002.4 MB per queue @ depth 8192
- mana_pre_alloc_rxbufs: 0000007:0000004 MB @ 64 queues / depth 8192

Failures occur on driver open and on runtime reconfig (channels, ring size, MTU).

Mellanox (mlx5) previously hit the same class of issue — large contiguous allocations (0000057:0000128 KB / 0000198:0000512 KB) failed on fragmented systems and were fixed by switching to smaller page-sized units.
2. Impact on Customer VMs

- Driver load failure → VM loses networking / availability.
- Runtime reconfig (ethtool, MTU) fails → blocks workload tuning.
- Worst on long-running VMs, high-memory workloads (AI/HPC, in-memory DBs), and max queue/ring configs (64 queues, depth 8192).
3. Reproduction Details (If Available)

- Trigger: High memory fragmentation + MANA driver load / queue reconfiguration.
- Symptom: kmalloc order-N allocation failure during mana_create_txq / mana_create_rxq / mana_pre_alloc_rxbufs; driver open/reconfig returns -ENOMEM.
- No deterministic repro; observed on fragmented systems and reproducible by forcing high-order allocation pressure.
4. Relationship to Larger Feature

None
5. Patch Criticality

- Medium
- Customer-visible loss of VM networking on memory fragmented systems on reloading driver or reconfiguring queue depth, queue size etc.
6. Classification (Select All That Apply)

- Bug fix – driver fails to load or reconfigure queues when contiguous high-order memory is unavailable due to memory fragmentation.
7. Upstream References

Upstream commit:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=3af0820c878e
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d07efe5a6e64

Request backport of the above patches to the active kernel versions. Thanks.

0000627: [AlmaLinux][MANA][Backport][Distros] porting patch: net: mana: Expose hardware diagnostic info via debugfs

Wed, 27 May 2026 13:00:42 +0000

Hello,

Problem Summary
Add debugfs entries to expose hardware configuration and diagnostic information that aids in debugging driver initialization and runtime operations without adding noise to dmesg.

The debugfs directory for each PCI device is named using pci_name() (the unique BDF address), and its creation and removal is integrated into mana_gd_setup() and mana_gd_cleanup_device() respectively, so that all callers (probe, remove, suspend, resume, shutdown) share a single code path.
Impact on Customer VMs
All VMs
Repro details
Additional details exposed from debugfs via this patch
Relationship to large feature
None
Patch Criticality
Medium

Request backport of the following patch to all active LTS Kernel versions.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c227f8aaf22c

0000626: [AlmaLInux][Backport][MANA] net: mana: validate rx_req_idx to prevent out-of-bounds array access

Wed, 27 May 2026 12:30:41 +0000

Hello,

This is a Sev 2 on our side with impact on all customer VM's

Problem Summary
In mana_hwc_rx_event_handler(), rx_req_idx is derived from
sge->address in DMA-coherent memory. In Confidential VMs
(SEV-SNP/TDX), this memory is shared unencrypted and HW can modify
WQE contents at any time. No bounds check exists on rx_req_idx,
which can lead to an out-of-bounds access into reqs[].

Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before
using it to index the reqs[] array.
Impact on Customer VMs
All VMs

Requesting backport of the below fix to all LTS kernels versions.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b809d0409991

0000625: ssss

Wed, 27 May 2026 12:29:10 +0000

ssss

0000624: [AlmaLinux][Backport][MANA] net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer

Thu, 21 May 2026 06:02:56 +0000

This is a Sev 2 on our side with customer facing issues.

Problem Summary
In mana_hwc_rx_event_handler(), resp->response.hwc_msg_id is read from
DMA-coherent memory and bounds-checked, then mana_hwc_handle_resp()
re-reads the same field from the same DMA buffer for test_bit() and
pointer arithmetic.

DMA-coherent memory is mapped uncacheable on x86 and is shared,
unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes
directly to host-visible memory. A H/W can modify the value
between the check and the use, bypassing the bounds validation.

Fix this by reading hwc_msg_id exactly once using READ_ONCE() into a
stack-local variable in mana_hwc_rx_event_handler(), and passing the
validated value as a parameter to mana_hwc_handle_resp().
Impact on Customer VMs
All VMs

Requesting backport of the below fix to all LTS kernels.

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=35f0f0a2536a