Rocky Linux BugTracker - Issues

0013399: GUI file copy fails with "Error splicing file: Bad file descriptor" on kernel 5.14.0-611.55.1.el9_7+ (regression vs 611.47.1.el9

Sat, 11 Jul 2026 07:52:25 +0000

Copying files via GNOME Files (Nautilus) fails with the error:

"Error while copying "". There was an error copying the file into . Error splicing file: Bad file descriptor"

This occurs on Rocky Linux 9.8 starting with kernel 5.14.0-611.55.1.el9_7 and reproduces on all subsequent kernels tested (5.14.0-687.12.1.el9_8, 5.14.0-687.15.1.el9_8, 5.14.0-687.17.1.el9_8). The last known-good kernel is 5.14.0-611.47.1.el9_7.

Command-line copy (cp) is NOT affected on any kernel version tested - only GUI copy operations performed through Nautilus (which use GLib/GIO's g_file_copy(), which internally uses splice() as a zero-copy optimization) fail.

In at least one reproduction, instead of showing the error dialog, the operation silently reported success while the destination file was created with 0 bytes - a data-integrity concern beyond the visible error.

0013333: dracut-live: 90dmsquash-live generates syntactically invalid udev rules on EL10 due to systemd-udevd v257 non-shell execution

Thu, 09 Jul 2026 15:14:56 +0000

NOTE: This issue was found with assistance from Gemini AI.

When booting a diskless live image via PXE using the standard loopback file argument (e.g., root=live:/microkernel.iso), the system boots to a timeout loop and drops into the Dracut emergency shell with the error:

dracut: FATAL: Failed to mount block device of live image

In the system journal, systemd-udevd reports:
systemd-udevd[504]: /etc/udev/rules.d/99-liveiso-mount.rules:1 Invalid key/value pair, ignoring.

0013366: Rocky 10 autofs indirect NFS map hangs while equivalent manual mount succeeds

Thu, 09 Jul 2026 12:14:30 +0000

On Rocky Linux 10.1 nodes, autofs hangs when accessing NFS exports through an indirect file map. The same NFS exports mount successfully with manual mount.nfs using equivalent options.

This was reproduced on Rocky 10.1 Kubernetes nodes..

Affected versions:
- Rocky Linux 10.1
- kernel: 6.12.0-124.49.1.el10_1.x86_64
- autofs: autofs-5.1.9-13.el10.x86_64
- nfs-utils: nfs-utils-2.8.3-0.el10_1.3.x86_64

Comparison node where autofs works:
- Rocky Linux 8.10
- autofs: autofs-5.1.4-113.el8.x86_64
- nfs-utils: nfs-utils-2.3.3-59.el8.x86_64

Manual NFS mount works on Rocky 10, but autofs access to the same export times out. A separate minimal test autofs map also times out, so the issue is not limited to the generated production map.

0013300: Rocky Linux 10 kernel-core: please confirm whether mlx4 Ethernet/InfiniBand support is intentionally disabled

Tue, 07 Jul 2026 17:21:12 +0000

Hello Rocky Linux kernel maintainers,

I am filing this as a kernel configuration and hardware support review request. This is not a security vulnerability report.

Short finding:

Rocky Linux 10.2 kernel-core currently does not provide the Mellanox mlx4 Ethernet and InfiniBand/RDMA drivers:

CONFIG_MLX4_EN=n
CONFIG_MLX4_INFINIBAND=n

In the collected comparison data, both options are available as loadable modules in Rocky Linux 9, AlmaLinux 10.2, Fedora 44, and the current cross-distribution peer majority.

Target evidence:

- Distribution: Rocky Linux 10.2
- Package/kernel: kernel-core 6.12.0-211.28.1.el10_2.x86_64
- Source package: https://dl.rockylinux.org/pub/rocky/10/BaseOS/x86_64/os/Packages/k/kernel-core-6.12.0-211.28.1.el10_2.x86_64.rpm
- Config SHA256: 0e14ff43128c938c98fb4c0eae16c0a8d32a3d914dd6825521c8ddf2f9a15167

Observed Rocky Linux 10.2 config values:

CONFIG_MLX4_EN=n
CONFIG_MLX4_INFINIBAND=n

Same-distribution previous major release check:

- Distribution: Rocky Linux 9
- Package/kernel: kernel-core 5.14.0-687.17.1.el9_8.x86_64
- Source package: http://dl.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/k/kernel-core-5.14.0-687.17.1.el9_8.x86_64.rpm
- Config SHA256: 0393136059b42e2428b44b3a31b3617c2eee868fe752560266bf5ddd4c886573
- Config values:
CONFIG_MLX4_EN=m
CONFIG_MLX4_INFINIBAND=m

Same-family comparison:

- AlmaLinux 10.2, kernel 6.12.0-211.29.1.el10_2.x86_64:
CONFIG_MLX4_EN=m
CONFIG_MLX4_INFINIBAND=m
Config SHA256: 626696bf9d16e8d45e6bb773e0d97d35bead78e42517a06cc1df6553da74b3ef

- Fedora 44, kernel 7.0.14-201.fc44.x86_64:
CONFIG_MLX4_EN=m
CONFIG_MLX4_INFINIBAND=m
Config SHA256: cce9847e91735edd71eedbec52877700a3564744e6e5a0e70a04164737cc2f8e

Cross-distribution comparison:

In the latest/current x86_64 kernel config comparison set collected on 2026-07-06 UTC, both options have peer majority value m:

- CONFIG_MLX4_EN: peer majority m, 11/11 peers
- CONFIG_MLX4_INFINIBAND: peer majority m, 11/11 peers

Why this may matter:

The mlx4 driver family supports Mellanox ConnectX-3 / ConnectX-3 Pro class Ethernet and InfiniBand/RDMA hardware. When these options are built as modules, users with relevant hardware can load the driver on demand. When they are set to n, Rocky Linux 10.2 kernel-core does not provide those drivers at all.

Questions:

1. Is Rocky Linux 10.2 intentionally disabling mlx4 Ethernet and InfiniBand/RDMA support in kernel-core?
2. If this is intentional, is there a release note, hardware support policy, or RHEL-compatible rationale documenting the removal?
3. If it is not intentional, would it be acceptable to restore CONFIG_MLX4_EN=m and CONFIG_MLX4_INFINIBAND=m in Rocky Linux 10.2, consistent with Rocky Linux 9 and AlmaLinux 10.2?
4. If this needs to be reproduced or confirmed against RHEL, please let me know what comparison target would be most useful.

Again, this is a hardware support / kernel configuration review request, not a claim of a security vulnerability.

Thanks.

0013301: Bad Epoll SIcherheitslücke (CVE-2026-46242)

Tue, 07 Jul 2026 09:36:48 +0000

Hallo,

ich nutze dieses Ticket um zu erfragen wie mit der Sicherheitslücke Bad Epoll umgegangen wird:
https://github.com/J-jaeyoung/bad-epoll

Ich finde keine Angabe auf den offiziellen Rocky Seiten, wann einen gepatchte Kernel Version angeboten werden wird.

0013102: gdm hand-off to gnome freezes mouse, keyboard and screen at password query screen

Mon, 06 Jul 2026 19:56:22 +0000

The update to gdm 1:40.1-44.el9_8 and gnome-shell 10.10-35.el9_8.1 leaves the user hanging at the gdm password query screen without access to mouse, keyboard or TTYs. Following an update with the Software Center, upon reboot, and after entering a password for a user or root, the system freezes leaving the user at the login screen without entering the gnome graphical environment. The problem persists across all saved kernels in GRUB but the recovery kernel is accessible.

0012970: dnf update fails with Depsolve Error on Rocky 9.6

Mon, 06 Jul 2026 16:40:56 +0000

Running dnf update produces the following errors which seem to be related to package name mismatch for selinux-policy and proj-data. There are some other bugs reported that are giving similar errors from the last few days, but for different OS versions/packages.

Depsolve Error occurred:
Problem 1: cannot install the best update candidate for package xrdp-selinux-1:0.10.6-1.el9.x86_64
- nothing provides selinux-policy >= 38.1.75-2.el9_8 needed by xrdp-selinux-1:0.10.6-2.el9.x86_64 from ceh-epel

Problem 2: package proj-data-at-9.6.0-3.el9.noarch from ceh-appstream requires proj-data = 9.6.0-3.el9, but none of the providers can be installed
- cannot install both proj-data-9.6.0-3.el9.noarch from ceh-appstream and proj-data-9.6.0-3.el9_7.noarch from @System
- cannot install the best update candidate for package proj-data-at-8.2.0-1.el9.noarch
- problem with installed package proj-data-9.6.0-3.el9_7.noarch

Problem 3: package proj-data-au-9.6.0-3.el9.noarch from ceh-appstream requires proj-data = 9.6.0-3.el9, but none of the providers can be installed
- cannot install both proj-data-9.6.0-3.el9.noarch from ceh-appstream and proj-data-9.6.0-3.el9_7.noarch from @System
- cannot install the best update candidate for package proj-data-au-8.2.0-1.el9.noarch
- cannot install the best update candidate for package proj-data-9.6.0-3.el9_7.noarch

Problem 4: package xrdp-selinux-1:0.10.6-1.el9.x86_64 from @System requires xrdp = 1:0.10.6-1.el9, but none of the providers can be installed
- cannot install both xrdp-1:0.10.6-2.el9.x86_64 from ceh-epel and xrdp-1:0.10.6-1.el9.x86_64 from @System
- problem with installed package xrdp-selinux-1:0.10.6-1.el9.x86_64
- cannot install the best update candidate for package xrdp-1:0.10.6-1.el9.x86_64
- nothing provides selinux-policy >= 38.1.75-2.el9_8 needed by xrdp-selinux-1:0.10.6-2.el9.x86_64 from ceh-epel

Problem 5: cannot install both proj-data-9.6.0-3.el9.noarch from ceh-appstream and proj-data-9.6.0-3.el9_7.noarch from @System
- package proj-data-be-9.6.0-3.el9.noarch from ceh-appstream requires proj-data = 9.6.0-3.el9, but none of the providers can be installed
- package proj-9.6.0-3.el9_7.x86_64 from @System requires proj-data = 9.6.0-3.el9_7, but none of the providers can be installed
- cannot install the best update candidate for package proj-data-be-8.2.0-1.el9.noarch
- problem with installed package proj-9.6.0-3.el9_7.x86_64

Problem 6: cannot install both proj-data-9.6.0-3.el9.noarch from ceh-appstream and proj-data-9.6.0-3.el9_7.noarch from @System
- package proj-data-br-9.6.0-3.el9.noarch from ceh-appstream requires proj-data = 9.6.0-3.el9, but none of the providers can be installed
- package proj-9.6.0-3.el9_7.x86_64 from @System requires proj-data = 9.6.0-3.el9_7, but none of the providers can be installed
- cannot install the best update candidate for package proj-data-br-8.2.0-1.el9.noarch
- cannot install the best update candidate for package proj-9.6.0-3.el9_7.x86_64

Problem 7: cannot install both proj-data-9.6.0-3.el9.noarch from ceh-appstream and proj-data-9.6.0-3.el9_7.noarch from @System
- package proj-9.6.0-3.el9_7.x86_64 from @System requires proj-data = 9.6.0-3.el9_7, but none of the providers can be installed
- package proj-data-ca-9.6.0-3.el9.noarch from ceh-appstream requires proj-data = 9.6.0-3.el9, but none of the providers can be installed
- package proj-devel-9.6.0-3.el9_7.x86_64 from @System requires proj(x86-64) = 9.6.0-3.el9_7, but none of the providers can be installed
- cannot install the best update candidate for package proj-data-ca-8.2.0-1.el9.noarch
- problem with installed package proj-devel-9.6.0-3.el9_7.x86_64

Problem 8: package proj-9.6.0-3.el9_7.x86_64 from @System requires proj-data = 9.6.0-3.el9_7, but none of the providers can be installed
- cannot install both proj-data-9.6.0-3.el9.noarch from ceh-appstream and proj-data-9.6.0-3.el9_7.noarch from @System
- package proj-devel-9.6.0-3.el9_7.x86_64 from @System requires proj(x86-64) = 9.6.0-3.el9_7, but none of the providers can be installed
- package proj-data-ch-9.6.0-3.el9.noarch from ceh-appstream requires proj-data = 9.6.0-3.el9, but none of the providers can be installed
- cannot install the best update candidate for package proj-devel-9.6.0-3.el9_7.x86_64
- cannot install the best update candidate for package proj-data-ch-8.2.0-1.el9.noarch

0013267: Please delete my account

Fri, 03 Jul 2026 08:53:19 +0000

Please delete my account with username
machine_monarch

Across all services
accounts.rockylinux.org
chat.rockylinux.org
and IRC

Associated e-mail is hello@machinemonarch.com

0013234: libX11 1.8.12-1 rebase causes xfce4-screensaver to hold input grab after KVM/USB reconnect on XFCE desktop

Thu, 02 Jul 2026 15:30:09 +0000

Title: libX11 1.8.12-1 rebase causes xfce4-screensaver to
hold input grab after KVM/USB reconnect on XFCE desktop

Component: libX11
Version: Rocky Linux 9.8

Summary:
After upgrading libX11 from 1.7.0-11.el9 (Rocky 9.6) to
1.8.12-1.el9 (Rocky 9.8), switching a KVM causes
xfce4-screensaver to hold an input grab that prevents
keyboard input and mouse clicks from reaching the XFCE
desktop. Mouse cursor movement works but no click/keyboard
events are processed.

Regression:
Working: libX11-1.7.0-11.el9 (Rocky 9.6)
Broken: libX11-1.8.12-1.el9 (Rocky 9.8)

Expected: Desktop input functions normally after KVM switch
Actual: Mouse moves but keyboard and mouse clicks are
frozen/ignored by XFCE desktop

Workaround:
killall xfce4-screensaver

Suspected cause:
The dont-forward-keycode-0.patch was updated for the 1.8.12
codebase. KVM switches generate keycode 0 events on USB
reconnect. The changed patch behavior appears to cause
xfce4-screensaver to incorrectly hold an input grab.

Related: RHEL-111537

0013201: nginx 1.26 security build breaks dynamic-module ABI

Wed, 01 Jul 2026 20:06:37 +0000

(copied from my post at https://forums.rockylinux.org/t/nginx-and-cve-2026-49975/20567/3)

Rocky linux broke nginx's dynamic module ABI in a patchlevel release, which causes segfaults on every request for anyone using nginx dynamic modules. The root cause is an added struct field in a public struct which nginx modules expect to remain stable within a major version. The patch came from nginx but was not backportable to earlier trees. Ubuntu had the same issue, see https://ubuntu.com/security/CVE-2026-49975#notes)

> nginx fixed this by releasing 1.29.8 with a max_headers directive with a default of 1000. They did not mention this release on their security page, and did not assign an nginx specific CVE to this issue. The nginx fix for this issue breaks ABI and introduced a regression causing nginx to crash when being used with external modules. The CVE fix was reverted in 8398-2. USN-8398-3 provided a complete fix for this issue.

Rocky has the same regression in `nginx-1.26.3-9.module+el9.8.0+40222+e48d13b6.1` (RLSA-2026:29151). The `max_headers` patch inserts a field into a public struct in `src/http/ngx_http_request.h`:

```console
$ dnf download --source nginx-1.26.3-9.module+el9.8.0+40222+e48d13b6.1
$ rpm2cpio nginx-*.src.rpm | cpio -idm --quiet
$ cat 0017-Added-max_headers-directive.patch
```
```diff
--- a/src/http/ngx_http_request.h
+++ b/src/http/ngx_http_request.h
typedef struct {
ngx_list_t headers;
+ ngx_uint_t count;
ngx_table_elt_t *host;
```

`ngx_http_headers_in_t` is embedded by value in `ngx_http_request_t`, so this shifts every following field. Modules built against the prior `1.26.3-9` respin then read `r->headers_in.*` at the wrong offsets and segfault on the first request (`worker process exited on signal 11`).

Normally `NGX_MODULE_SIGNATURE` would refuse an incompatible module at load time, but it only encodes struct-*affecting build options*, not source-level struct changes — so it's byte-identical across both builds and the module loads, then crashes:

```console
$ for b in 40194+40adfc1b 40222+e48d13b6.1; do
dnf download "nginx-core-1.26.3-9.module+el9.8.0+$b" >/dev/null 2>&1
printf '%s ' "$b"
rpm2cpio nginx-core-*"$b"*.rpm | cpio --to-stdout -i --quiet ./usr/sbin/nginx \
| strings | grep -m1 -E '^[0-9]+,[0-9]+,[0-9]+,'
done
40194+40adfc1b 8,4,8,0011111111010111011111111111111111
40222+e48d13b6.1 8,4,8,0011111111010111011111111111111111 # identical, yet ABI differs
```

Like Ubuntu did in USN-8398-3, this needs a respin that either drops the `max_headers` struct change from the 1.26 z-stream or bumps a signature-affecting identifier so mismatched modules fail to load instead of segfaulting at runtime.

I also reported this upstream to redhat in https://bugzilla.redhat.com/show_bug.cgi?id=2480746.

0013168: kernel: iTCO_wdt watchdog pretimeout panic after KVM host suspend/resume

Wed, 01 Jul 2026 11:46:06 +0000

After suspending the KVM host for >= 1 minute and resuming, the Rocky
Linux 10.2 guest kernel panics with "watchdog pretimeout event" and
resets. The panic is 100% reproducible with suspend duration >= 1
minute. Does NOT occur on Rocky Linux 10.1 under identical conditions.

Host environment:
OS: Ubuntu 24.04.4 LTS
Kernel: 6.17.0-35-generic
CPU: AMD Ryzen 7 6800H
QEMU: 8.2.2
libvirt: 10.0.0

Guest environment:
OS: Rocky Linux 10.2
Kernel: 6.12.0-211.26.1.el10_2.x86_64
Machine: Q35 + ICH9
Install type: Minimal installation (no GUI, no extra packages)
Watchdog: (libvirt XML)
Modules: iTCO_wdt, iTCO_vendor_support

Workaround: blacklist iTCO_wdt and iTCO_vendor_support in the guest.

This was also reported to upstream linux-watchdog mailing list.
Upstream maintainer Guenter Roeck indicated the bug may be specific
to downstream kernel patches and suggested filing with the distribution.

Upstream thread:
https://lore.kernel.org/linux-watchdog/odOoKUew64I3M0Rw7X5VzzgGB3eAx_dZ355qK2bC6cH7tfmBGLGLaq8C1idS0FO6e0iy-yyZhT91T1qisUuZfw9Ho8fa0nSiY4QBRh3oosk=@proton.me/

0013135: 9.8 repos provide oudated nss package, while 9.7 have an newer one

Tue, 30 Jun 2026 13:23:53 +0000

This is observed for the nss package. I did not check other packages but it is probable that other packages are affected.

So, coming from an 9.7 installation where nss-3.112.0-8.el9_7 is installed I updated to 9.8.

While checking the upgrade with dnf distrosync I noticed that dnf wants to downgrade nss to nss-3.112.0-8.el9

Current installed version (from 9.7 while running 9.8)

# rpm -qi nss |grep -E '^Name|Build D'
Name : nss
Build Date : Fr 03 Apr 2026 18:35:15 CEST

Package from 9.8 repos

# rpm -qpi nss-3.112.0-8.el9.x86_64.rpm |grep -E '^Name|Build D'
Name : nss
Build Date : Di 27 Jan 2026 04:36:55 CET

So the 9.7 nss package is "newer" (build) then the 9.8 package.

For instance, a new setup will not have the same state compared to a node that was updated.

Suggestions

- Even when the package code has not been changed a dnf distrosync should not downgrade a package
- Even when a package does not change between minor releases, it (the repo) should provide the latest build.

This suggestions supports integrity checks of the OS.
So the current repo state or name it glitches do have a big impact.

This got our attention because nss is security related.

0012508: mdadm-4.4-4.el9_7 fails to assemble arrays: "Can't open /sys/module/md_mod/parameters/legacy_async_del_gendisk"

Wed, 24 Jun 2026 00:20:41 +0000

Description:

Server was last booted +/- 90 days ago. No problems at that time.
Suspect after the mdadm-4.4-4.el9_7 update (installed 2026-04-11), mdadm --assemble --scan (and automatic boot assembly) fails with:
mdadm: Can't open /sys/module/md_mod/parameters/legacy_async_del_gendisk
mdadm: init md module parameters fail
mdadm: No arrays found in config file or automatically

Affected systems:

Rocky Linux 9.7 (Blue Onyx) per /etc/rocky-release
Kernel: 5.14.0-570.32.1.el9_6.x86_64 (Rocky 9.6 kernel series)
mdadm: 4.4-4.el9_7.x86_64
RAID: RAID10 (near=2, 256K chunks) built on 4× partitions (/dev/sda1–/dev/sdd1)
LVM on top of /dev/md0

0012343: collectd write_riemann always crashing on Rocky 9.7

Tue, 23 Jun 2026 23:38:58 +0000

I'm getting stacktrace from collectd write_riemann plugin, which is using riemann-c-client, when collectd is trying to send metrics. I didn't have these issues before. Stacktrace details:

```
Process 4729 (collectd) of user 0 dumped core.
Stack trace of thread 4732:
#0 0x00007f52f075d5bd __strlen_avx2 (libc.so.6 + 0x15d5bd)
#1 0x00007f52f069c6c3 __strdup (libc.so.6 + 0x9c6c3)
#2 0x00007f52f05f991c riemann_event_set_va (libriemann-client.so.0 + 0x591c)
#3 0x00007f52f05f9e81 riemann_event_set (libriemann-client.so.0 + 0x5e81)
#4 0x00007f52f0813f6c wrr_value_to_event (write_riemann.so + 0x2f6c)
#5 0x00007f52f0814463 wrr_value_list_to_message (write_riemann.so + 0x3463)
#6 0x00007f52f0814bc3 wrr_write (write_riemann.so + 0x3bc3)
#7 0x000055a706ee4b9e plugin_write (collectd + 0x10b9e)
#8 0x000055a706ee6d85 fc_bit_write_invoke.lto_priv.0 (collectd + 0x12d85)
#9 0x000055a706ef23ff plugin_dispatch_values_internal.isra.0 (collectd + 0x1e3ff)
#10 0x000055a706ee01f7 plugin_write_thread (collectd + 0xc1f7)
#11 0x00007f52f068a19a start_thread (libc.so.6 + 0x8a19a)
#12 0x00007f52f070f210 __clone3 (libc.so.6 + 0x10f210)

Stack trace of thread 4738:
#0 0x00007f52f068ef6a __GI___pthread_mutex_unlock_usercnt (libc.so.6 + 0x8ef6a)
#1 0x000055a706ee1264 plugin_write_enqueue (collectd + 0xd264)
#2 0x000055a706ee1817 plugin_dispatch_values (collectd + 0xd817)
#3 0x00007f52f089f66f disk_submit (disk.so + 0x166f)
#4 0x00007f52f08a00a4 disk_read (disk.so + 0x20a4)
#5 0x000055a706ee44bc plugin_read_thread (collectd + 0x104bc)
#6 0x00007f52f068a19a start_thread (libc.so.6 + 0x8a19a)
#7 0x00007f52f070f210 __clone3 (libc.so.6 + 0x10f210)
```
I've reported this to riemann-c-client maintaner (https://git.madhouse-project.org/algernon/riemann-c-client/issues/17) and he suspects it's something either due to collectd or packaging. However, I'm running collectd 5.12.0 and riemann-c-client 1.10.4 on Debian 13 without any issue

Also, rieman-c-client might need update on Rocky as well.

0012409: AMD EPYC 9535 Fails to boot Rocky 9.7 due to microcode update failing

Mon, 22 Jun 2026 15:31:59 +0000

System cannot boot Rocky 9.7 due to microcode update failing but worked fine using 9.6. Using dis_ucode_ldr in kernel arguments fixes issue on 9.7. Both an update from 9.6 to 9.7 and a fresh 9.7 install were attempted.

0012211: SELinux regression in selinux-policy-42.1.7-1.el10_1.1 causes systemd AVC denial (init_t capability2 mac_admin) and breaks syste

Mon, 15 Jun 2026 17:23:04 +0000

After upgrading to selinux-policy-42.1.7-1.el10_1.1 on Rocky Linux 10.1, SELinux starts denying the mac_admin capability for systemd (init_t). This results in repeated AVC denials and causes system services to malfunction. In our environment this manifests as failures when managing services (for example via systemctl or automation tools such as Ansible).

Downgrading SELinux policy packages to 42.1.7-1.el10 resolves the issue immediately.

Working versions:

selinux-policy-42.1.7-1.el10.noarch
selinux-policy-targeted-42.1.7-1.el10.noarch
systemd-257-13.el10.rocky.0.1.x86_64
dbus-broker-36-4.el10.x86_64

Broken versions:

selinux-policy-42.1.7-1.el10_1.1.noarch
selinux-policy-targeted-42.1.7-1.el10_1.1.noarch

0012180: Trusted Domain Authentication samba 4.22 Rocky 9.7

Mon, 15 Jun 2026 12:01:41 +0000

Samba 4.22.4-12.el9_7 doesn't seem to contain the regression anymore for CVE-2025-49716 netlogon hardening fix

- **OS**: Rocky Linux 9.7 (Blue Onyx)
- **Samba Version**: samba-4.22.4-12.el9_7.x86_64
- **Configuration**: Domain member server joined to DOMAIN-A.COM with forest transitive trust to DOMAIN-B.COM
- **idmap backend**: ad (for DOMAIN-B), sss (for DOMAIN-A)

After upgrading from Rocky Linux 9.6 (samba-4.21.3-14.el9_6) to Rocky Linux 9.7 (samba-4.22.4-12.el9_7), NTLM challenge/response authentication fails for users from the trusted domain DOMAIN-B.COM with `NT_STATUS_WRONG_PASSWORD`. Plaintext authentication works correctly.

[log.wb-DOMAIN-B] cm_connect_netlogon_transport: get_secure_channel_type gave SEC_CHAN_NULL for DOMAIN-B
[log.wb-DOMAIN-B] cli_rpc_pipe_open_noauth: opened pipe netlogon to machine DC01.domain-b.com and bound anonymously
[log.winbindd] lm_resp: DATA_BLOB length=0
[log.winbindd] nt_resp: DATA_BLOB length=0
[log.winbindd] result: NT_STATUS_WRONG_PASSWORD

No `netr_LogonSamLogon` calls found in logs - winbind not attempting netlogon authentication for trusted domain challenge/response.

0011980: On Rocky Linux 9, perl-DBD-MySQL-4.053-1.el9.0.1.x86_64 has a hard runtime dependency on libmysqlclient.so.21

Mon, 15 Jun 2026 10:08:35 +0000

On Rocky Linux 9, perl-DBD-MySQL-4.053-1.el9.0.1.x86_64 has a hard runtime dependency on libmysqlclient.so.21 -
This makes perl-DBD-MySQL incompatible with Percona Server packages - (percona-server-shared) which obsolete mysql-libs.

On RHEL 9, perl-DBD-MySQL is available in a build (4.050-13.el9) which uses mariadb-connector-c and does not require libmysqlclient.so.21, and therefore works correctly with Percona Server.

As a result, percona-xtrabackup-84 cannot be installed on Rocky 9 when Percona Server is present, while the same setup works on RHEL 9.

Please consider rebuilding perl-DBD-MySQL on Rocky 9 against mariadb-connector-c (as in RHEL), or providing a compatible build as this differs from RHEL spec / behavior.

0012179: Security update for CVE-2025-14104 missing for Rocky 9.7 util-linux package

Mon, 15 Jun 2026 10:00:10 +0000

The security updates for CVE-2025-14104 were provided as following:

- el8: [util-linux-0:2.32.1-48.el8_10] via RHSA-2026:1852 (2026-02-04) <-- This was made available on 2026-02-05
- el9: [util-linux-0:2.37.4-21.el9_7] via RHSA-2026:1913 (2026-02-04) <-- Still missing (not the same as util-linux-0:2.37.4-21.el9)

The https://errata.rockylinux.org/RLSA-2026:1913 does not appear to denote the correct version for this security update. It references util-linux-0:2.37.4-21.el9 (which was released 2025-05-03 and does not contain the security fix in question (refer to additional information for first 10 lines of changelogs).

Can this security update be made available for the Rocky el9.7 release?

0012575: postgis package is available in appstream, whereas in RHEL 9 it is only available in the postgresql:16 module

Mon, 15 Jun 2026 09:51:18 +0000

RHEL 9.7 added the postgis package, but it is supported only in the postgresql:16 module stream. It is not available in "appstream". In Rocky Linux 9.7 it is available as a module package as well as in a non-modular version. This forms an incompatibility with upstream. The non-modular package shall be removed.

0012310: kernels > 6.12.0-68.el10: data loss when using md raid1 with with writemostly flag

Mon, 15 Jun 2026 09:50:28 +0000

The current redhat kernels 6.12.0-124.40.1.el10_1 on EL10 and 5.14.0-611.36.1.el9_7 on EL9 contain a regression that leads to data-loss if a raid1 is configured with one disk flagged as writemostly.

The regression was introduced by this linux kernel commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8a0adf3d778c4a0893c6d34a9e1b0082a6f1c495

It was backported to EL10 and EL9:

EL10:
* Mon Mar 24 2025 Julio Faracco <jfaracco@redhat.com> [6.12.0-68.el10]
- md/raid1,raid10: don't ignore IO flags (Nigel Croxon) [RHEL-83951]

EL9:
* Thu Mar 27 2025 Augusto Caringi <acaringi@redhat.com> [5.14.0-576.el9]
- md/raid1,raid10: don't ignore IO flags (Nigel Croxon) [RHEL-83988]

The mainline kernel already contains a fix:

https://github.com/torvalds/linux/commit/743bf030947169c413a711f60cebe73f837e649f

However this fix didn't make it into redhat kernels yet.

0012079: 10.x devel repository mirrors not working

Mon, 15 Jun 2026 09:37:28 +0000

Enabling the "Devel" repository for 10.0 and 10.x fails. It stopped working sometime in the last couple of months or so.

A similar bug was previously reported for 9.x: https://bugs.rockylinux.org/view.php?id=3268

Note that this is in the context of building a custom Docker image within a GitHub Actions workflow, based on rockylinux/rockylinux from Docker Hub.

0012574: category "postgis" missing for Rocky Linux 9

Mon, 15 Jun 2026 09:33:17 +0000

The BugTracker does not have the "postgis" category for Rocky Linux 9 (postgis is a new package since 9.7). It should be added.

0012706: /lib64/libwebkit2gtk-4.1.so.4 undefined symbol

Mon, 15 Jun 2026 09:10:03 +0000

stremtan@zamolxis:~$ ldd -r /lib64/libwebkit2gtk-4.1.so.0 | grep gst
libgstallocators-1.0.so.0 => /lib64/libgstallocators-1.0.so.0 (0x00007fc9a71c8000)
libgstapp-1.0.so.0 => /lib64/libgstapp-1.0.so.0 (0x00007fc9a71b1000)
libgstbase-1.0.so.0 => /lib64/libgstbase-1.0.so.0 (0x00007fc9a7125000)
libgstreamer-1.0.so.0 => /lib64/libgstreamer-1.0.so.0 (0x00007fc9a6fd4000)
libgstpbutils-1.0.so.0 => /lib64/libgstpbutils-1.0.so.0 (0x00007fc9a6f90000)
libgstaudio-1.0.so.0 => /lib64/libgstaudio-1.0.so.0 (0x00007fc9a6f09000)
libgsttag-1.0.so.0 => /lib64/libgsttag-1.0.so.0 (0x00007fc9a6ec8000)
libgstvideo-1.0.so.0 => /lib64/libgstvideo-1.0.so.0 (0x00007fc9a6df9000)
libgstgl-1.0.so.0 => /lib64/libgstgl-1.0.so.0 (0x00007fc9a6d6a000)
libgstfft-1.0.so.0 => /lib64/libgstfft-1.0.so.0 (0x00007fc9a6d5e000)
undefined symbol: gst_structure_foreach_id_str (/lib64/libwebkit2gtk-4.1.so.0)
undefined symbol: gst_id_str_as_str (/lib64/libwebkit2gtk-4.1.so.0)

0012939: Lock screen does not prompt for password

Mon, 15 Jun 2026 09:05:35 +0000

After I lock the screen I can resume back-in without a password prompt. The lock screen can be done via Ctrl+L, idle time, or from the Lock screen menu, the same result.