Описание
Security update for the Linux Kernel (Live Patch 37 for SUSE Linux Enterprise 15 SP4)
This update for the SUSE Linux Enterprise Kernel 5.14.21-150400.24.153 fixes various security issues
The following security issues were fixed:
- CVE-2025-39973: i40e: add validation for ring_len param (bsc#1252036).
- CVE-2025-40018: ipvs: Defer ip_vs_ftp unregister during netns cleanup (bsc#1252689).
- CVE-2025-71120: SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf (bsc#1256780).
- CVE-2026-22999: net/sched: sch_qfq: do not free existing class in qfq_change_class() (bsc#1257238).
- CVE-2026-23074: net/sched: Enforce that teql can only be used as root qdisc (bsc#1258051).
- CVE-2026-23209: macvlan: fix error recovery in macvlan_common_newlink() (bsc#1258784).
Список пакетов
SUSE Linux Enterprise Live Patching 15 SP4
Ссылки
- Link for SUSE-SU-2026:1269-1
- E-Mail link for SUSE-SU-2026:1269-1
- SUSE Security Ratings
- SUSE Bug 1252036
- SUSE Bug 1252689
- SUSE Bug 1256780
- SUSE Bug 1257238
- SUSE Bug 1258051
- SUSE Bug 1258784
- SUSE CVE CVE-2025-39973 page
- SUSE CVE CVE-2025-40018 page
- SUSE CVE CVE-2025-71120 page
- SUSE CVE CVE-2026-22999 page
- SUSE CVE CVE-2026-23074 page
- SUSE CVE CVE-2026-23209 page
Описание
In the Linux kernel, the following vulnerability has been resolved: i40e: add validation for ring_len param The `ring_len` parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation. To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.
Затронутые продукты
Ссылки
- CVE-2025-39973
- SUSE Bug 1247374
- SUSE Bug 1252035
- SUSE Bug 1252036
Описание
In the Linux kernel, the following vulnerability has been resolved: ipvs: Defer ip_vs_ftp unregister during netns cleanup On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free. Fix this by introducing a global `exiting_module` flag, set to true in ip_vs_ftp_exit() before unregistering the pernet subsystem. In __ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns cleanup (when exiting_module is false) and defer it to __ip_vs_cleanup_batch(), which unregisters all apps after all connections are flushed. If called during module exit, unregister ip_vs_ftp immediately.
Затронутые продукты
Ссылки
- CVE-2025-40018
- SUSE Bug 1247374
- SUSE Bug 1252688
- SUSE Bug 1252689
- SUSE Bug 1253291
Описание
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf A zero length gss_token results in pages == 0 and in_token->pages[0] is NULL. The code unconditionally evaluates page_address(in_token->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.
Затронутые продукты
Ссылки
- CVE-2025-71120
- SUSE Bug 1256779
- SUSE Bug 1256780
Описание
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: do not free existing class in qfq_change_class() Fixes qfq_change_class() error case. cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.
Затронутые продукты
Ссылки
- CVE-2026-22999
- SUSE Bug 1257236
- SUSE Bug 1257238
Описание
In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. Although not important, I will describe the scenario that unearthed this issue for the curious. GangMin Kim <km.kim1503@gmail.com> managed to concot a scenario as follows: ROOT qdisc 1:0 (QFQ) ├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s ── class 1:2 (weight=1, lmax=1514) teql GangMin sends a packet which is enqueued to 1:1 (netem). Any invocation of dequeue by QFQ from this class will not return a packet until after 6.4s. In the meantime, a second packet is sent and it lands on 1:2. teql's enqueue will return success and this will activate class 1:2. Main issue is that teql only updates the parent visible qlen (sch->q.qlen) at dequeue. Since QFQ will only call dequeue if peek succeeds (and teql's peek always returns NULL), dequeue will never be called and thus the qlen will remain as 0. With that in mind, when GangMin updates 1:2's lmax value, the qfq_change_class calls qfq_deact_rm_from_agg. Since the child qdisc's qlen was not incremented, qfq fails to deactivate the class, but still frees its pointers from the aggregate. So when the first packet is rescheduled after 6.4 seconds (netem's delay), a dangling pointer is accessed causing GangMin's causing a UAF.
Затронутые продукты
Ссылки
- CVE-2026-23074
- SUSE Bug 1257749
- SUSE Bug 1258051
- SUSE Bug 1263682
Описание
In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: <quote valis> The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). </quote valis> With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever "goto destroy_macvlan_port;" path is taken. Many thanks to valis for following up on this issue.
Затронутые продукты
Ссылки
- CVE-2026-23209
- SUSE Bug 1258518
- SUSE Bug 1258784