Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

suse-cvrf логотип

SUSE-SU-2026:1668-1

Опубликовано: 01 мая 2026
Источник: suse-cvrf

Описание

Security update for the Linux Kernel

The SUSE Linux Enterprise 12 SP5 kernel was updated to fix various security issues

The following security issues were fixed:

  • CVE-2024-26584: net/tls: return ENOTSUPP on tls_init() (bsc#1220186).
  • CVE-2025-38234: sched/rt: Fix race in push_rt_task (bsc#1246057).
  • CVE-2025-39759: btrfs: qgroup: fix race between quota disable and quota rescan ioctl (bsc#1249522).
  • CVE-2025-71268: btrfs: fix reservation leak in some error paths when inserting inline extent (bsc#1259865).
  • CVE-2025-71269: btrfs: do not free data reservation in fallback from inline due to -ENOSPC (bsc#1259889).
  • CVE-2026-22990: libceph: replace overzealous BUG_ON in osdmap_apply_incremental() (bsc#1257221).
  • CVE-2026-23103: ipvlan: Make the addrs_lock be per port (bsc#1257773).
  • CVE-2026-23120: l2tp: avoid one data-race in l2tp_tunnel_del_work() (bsc#1258280).
  • CVE-2026-23243: RDMA/umad: Reject negative data_len in ib_umad_write (bsc#1259797).
  • CVE-2026-23262: gve: Fix stats report corruption on queue count change (bsc#1259870).
  • CVE-2026-23272: netfilter: nf_tables: unconditionally bump set-nelems before insertion (bsc#1260009).
  • CVE-2026-23277: net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit (bsc#1259997).
  • CVE-2026-23318: ALSA: usb-audio: Use correct version for UAC3 header validation (bsc#1260536).
  • CVE-2026-23362: can: bcm: fix locking for bcm_op runtime updates (bsc#1260489).
  • CVE-2026-23382: HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them (bsc#1260551).
  • CVE-2026-23386: gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPL (bsc#1260799).
  • CVE-2026-23398: icmp: fix NULL pointer dereference in icmp_tag_validation() (bsc#1260730).

The following non security issues were fixed:

  • btrfs: fix processing of delayed data refs during backref walking (bsc#1228031).
  • fs: skip superblock shrink on frozen xfs filesystems (bsc#1259770).

Список пакетов

Image SLES12-SP5-Azure-BYOS
kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS
kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS
cluster-md-kmp-default-4.12.14-122.299.1
dlm-kmp-default-4.12.14-122.299.1
gfs2-kmp-default-4.12.14-122.299.1
kernel-default-4.12.14-122.299.1
ocfs2-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-On-Demand
cluster-md-kmp-default-4.12.14-122.299.1
dlm-kmp-default-4.12.14-122.299.1
gfs2-kmp-default-4.12.14-122.299.1
kernel-default-4.12.14-122.299.1
ocfs2-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-EC2-BYOS
kernel-default-4.12.14-122.299.1
Image SLES12-SP5-EC2-ECS-On-Demand
kernel-default-4.12.14-122.299.1
Image SLES12-SP5-EC2-On-Demand
kernel-default-4.12.14-122.299.1
Image SLES12-SP5-EC2-SAP-BYOS
cluster-md-kmp-default-4.12.14-122.299.1
dlm-kmp-default-4.12.14-122.299.1
gfs2-kmp-default-4.12.14-122.299.1
kernel-default-4.12.14-122.299.1
ocfs2-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-EC2-SAP-On-Demand
cluster-md-kmp-default-4.12.14-122.299.1
dlm-kmp-default-4.12.14-122.299.1
gfs2-kmp-default-4.12.14-122.299.1
kernel-default-4.12.14-122.299.1
ocfs2-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-GCE-BYOS
kernel-default-4.12.14-122.299.1
Image SLES12-SP5-GCE-On-Demand
kernel-default-4.12.14-122.299.1
Image SLES12-SP5-GCE-SAP-BYOS
cluster-md-kmp-default-4.12.14-122.299.1
dlm-kmp-default-4.12.14-122.299.1
gfs2-kmp-default-4.12.14-122.299.1
kernel-default-4.12.14-122.299.1
ocfs2-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-GCE-SAP-On-Demand
cluster-md-kmp-default-4.12.14-122.299.1
dlm-kmp-default-4.12.14-122.299.1
gfs2-kmp-default-4.12.14-122.299.1
kernel-default-4.12.14-122.299.1
ocfs2-kmp-default-4.12.14-122.299.1
SUSE Linux Enterprise Live Patching 12 SP5
kernel-default-kgraft-4.12.14-122.299.1
kernel-default-kgraft-devel-4.12.14-122.299.1
kgraft-patch-4_12_14-122_299-default-1-8.3.1
SUSE Linux Enterprise Server 12 SP5-LTSS
cluster-md-kmp-default-4.12.14-122.299.1
dlm-kmp-default-4.12.14-122.299.1
gfs2-kmp-default-4.12.14-122.299.1
kernel-default-4.12.14-122.299.1
kernel-default-base-4.12.14-122.299.1
kernel-default-devel-4.12.14-122.299.1
kernel-default-man-4.12.14-122.299.1
kernel-devel-4.12.14-122.299.1
kernel-macros-4.12.14-122.299.1
kernel-source-4.12.14-122.299.1
kernel-syms-4.12.14-122.299.1
ocfs2-kmp-default-4.12.14-122.299.1
SUSE Linux Enterprise Server LTSS Extended Security 12 SP5
cluster-md-kmp-default-4.12.14-122.299.1
dlm-kmp-default-4.12.14-122.299.1
gfs2-kmp-default-4.12.14-122.299.1
kernel-default-4.12.14-122.299.1
kernel-default-base-4.12.14-122.299.1
kernel-default-devel-4.12.14-122.299.1
kernel-devel-4.12.14-122.299.1
kernel-macros-4.12.14-122.299.1
kernel-source-4.12.14-122.299.1
kernel-syms-4.12.14-122.299.1
ocfs2-kmp-default-4.12.14-122.299.1

Описание

In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: sched/rt: Fix race in push_rt_task Overview ======== When a CPU chooses to call push_rt_task and picks a task to push to another CPU's runqueue then it will call find_lock_lowest_rq method which would take a double lock on both CPUs' runqueues. If one of the locks aren't readily available, it may lead to dropping the current runqueue lock and reacquiring both the locks at once. During this window it is possible that the task is already migrated and is running on some other CPU. These cases are already handled. However, if the task is migrated and has already been executed and another CPU is now trying to wake it up (ttwu) such that it is queued again on the runqeue (on_rq is 1) and also if the task was run by the same CPU, then the current checks will pass even though the task was migrated out and is no longer in the pushable tasks list. Crashes ======= This bug resulted in quite a few flavors of crashes triggering kernel panics with various crash signatures such as assert failures, page faults, null pointer dereferences, and queue corruption errors all coming from scheduler itself. Some of the crashes: -> kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx >= MAX_RT_PRIO) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? pick_next_task_rt+0x6e/0x1d0 ? do_error_trap+0x64/0xa0 ? pick_next_task_rt+0x6e/0x1d0 ? exc_invalid_op+0x4c/0x60 ? pick_next_task_rt+0x6e/0x1d0 ? asm_exc_invalid_op+0x12/0x20 ? pick_next_task_rt+0x6e/0x1d0 __schedule+0x5cb/0x790 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb -> BUG: kernel NULL pointer dereference, address: 00000000000000c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? __warn+0x8a/0xe0 ? exc_page_fault+0x3d6/0x520 ? asm_exc_page_fault+0x1e/0x30 ? pick_next_task_rt+0xb5/0x1d0 ? pick_next_task_rt+0x8c/0x1d0 __schedule+0x583/0x7e0 ? update_ts_time_stats+0x55/0x70 schedule_idle+0x1e/0x40 do_idle+0x15e/0x200 cpu_startup_entry+0x19/0x20 start_secondary+0x117/0x160 secondary_startup_64_no_verify+0xb0/0xbb -> BUG: unable to handle page fault for address: ffff9464daea5900 kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq->cpu != task_cpu(p)) -> kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq->nr_running) Call Trace: ? __die_body+0x1a/0x60 ? die+0x2a/0x50 ? do_trap+0x85/0x100 ? dequeue_top_rt_rq+0xa2/0xb0 ? do_error_trap+0x64/0xa0 ? dequeue_top_rt_rq+0xa2/0xb0 ? exc_invalid_op+0x4c/0x60 ? dequeue_top_rt_rq+0xa2/0xb0 ? asm_exc_invalid_op+0x12/0x20 ? dequeue_top_rt_rq+0xa2/0xb0 dequeue_rt_entity+0x1f/0x70 dequeue_task_rt+0x2d/0x70 __schedule+0x1a8/0x7e0 ? blk_finish_plug+0x25/0x40 schedule+0x3c/0xb0 futex_wait_queue_me+0xb6/0x120 futex_wait+0xd9/0x240 do_futex+0x344/0xa90 ? get_mm_exe_file+0x30/0x60 ? audit_exe_compare+0x58/0x70 ? audit_filter_rules.constprop.26+0x65e/0x1220 __x64_sys_futex+0x148/0x1f0 do_syscall_64+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x62/0xc7 -> BUG: unable to handle page fault for address: ffff8cf3608bc2c0 Call Trace: ? __die_body+0x1a/0x60 ? no_context+0x183/0x350 ? spurious_kernel_fault+0x171/0x1c0 ? exc_page_fault+0x3b6/0x520 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? asm_exc_page_fault+0x1e/0x30 ? _cond_resched+0x15/0x30 ? futex_wait_queue_me+0xc8/0x120 ? futex_wait+0xd9/0x240 ? try_to_wake_up+0x1b8/0x490 ? futex_wake+0x78/0x160 ? do_futex+0xcd/0xa90 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? plist_del+0x6a/0xd0 ? plist_check_list+0x15/0x40 ? plist_check_list+0x2e/0x40 ? dequeue_pushable_task+0x20/0x70 ? __schedule+0x382/0x7e0 ? asm_sysvec_reschedule_i ---truncated---


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix race between quota disable and quota rescan ioctl There's a race between a task disabling quotas and another running the rescan ioctl that can result in a use-after-free of qgroup records from the fs_info->qgroup_tree rbtree. This happens as follows: 1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan(); 2) Task B enters btrfs_quota_disable() and calls btrfs_qgroup_wait_for_completion(), which does nothing because at that point fs_info->qgroup_rescan_running is false (it wasn't set yet by task A); 3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock; 4) Task A enters qgroup_rescan_zero_tracking() which starts iterating the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock, but task B is freeing qgroup records from that tree without holding the lock, resulting in a use-after-free. Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config(). Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas were already disabled.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reservation leak in some error paths when inserting inline extent If we fail to allocate a path or join a transaction, we return from __cow_file_range_inline() without freeing the reserved qgroup data, resulting in a leak. Fix this by ensuring we call btrfs_qgroup_free_data() in such cases.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not free data reservation in fallback from inline due to -ENOSPC If we fail to create an inline extent due to -ENOSPC, we will attempt to go through the normal COW path, reserve an extent, create an ordered extent, etc. However we were always freeing the reserved qgroup data, which is wrong since we will use data. Fix this by freeing the reserved qgroup data in __cow_file_range_inline() only if we are not doing the fallback (ret is <= 0).


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: libceph: replace overzealous BUG_ON in osdmap_apply_incremental() If the osdmap is (maliciously) corrupted such that the incremental osdmap epoch is different from what is expected, there is no need to BUG. Instead, just declare the incremental osdmap to be invalid.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: l2tp: avoid one data-race in l2tp_tunnel_del_work() We should read sk->sk_socket only when dealing with kernel sockets. syzbot reported the following data-race: BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 value changed: 0xffff88811b818000 -> 0x0000000000000000


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: RDMA/umad: Reject negative data_len in ib_umad_write ib_umad_write computes data_len from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, data_len can become negative and reach ib_create_send_mad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in alloc_send_rmpp_list(). Add an explicit check to reject negative data_len before creating the send buffer. KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102 [ 211.365867] ib_create_send_mad+0xa01/0x11b0 [ 211.365887] ib_umad_write+0x853/0x1c80


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: gve: Fix stats report corruption on queue count change The driver and the NIC share a region in memory for stats reporting. The NIC calculates its offset into this region based on the total size of the stats region and the size of the NIC's stats. When the number of queues is changed, the driver's stats region is resized. If the queue count is increased, the NIC can write past the end of the allocated stats region, causing memory corruption. If the queue count is decreased, there is a gap between the driver and NIC stats, leading to incorrect stats reporting. This change fixes the issue by allocating stats region with maximum size, and the offset calculation for NIC stats is changed to match with the calculation of the NIC.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally bump set->nelems before insertion In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already. To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state. As for element updates, decrement set->nelems to restore it. A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit teql_master_xmit() calls netdev_start_xmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand. When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnel_xmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnel_xmit_stats(dev, pkt_len). This function does: get_cpu_ptr(dev->tstats) Since teql_master_setup() does not set dev->pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. get_cpu_ptr(NULL) computes NULL + __per_cpu_offset[cpu], resulting in a page fault. BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnel_xmit (./include/net/ip_tunnels.h:664 net/ipv4/ip_tunnel_core.c:89) Call Trace: <TASK> ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847) __gre_xmit (net/ipv4/ip_gre.c:478) gre_tap_xmit (net/ipv4/ip_gre.c:779) teql_master_xmit (net/sched/sch_teql.c:319) dev_hard_start_xmit (net/core/dev.c:3887) sch_direct_xmit (net/sched/sch_generic.c:347) __dev_queue_xmit (net/core/dev.c:4802) neigh_direct_output (net/core/neighbour.c:1660) ip_finish_output2 (net/ipv4/ip_output.c:237) __ip_finish_output.part.0 (net/ipv4/ip_output.c:315) ip_mc_output (net/ipv4/ip_output.c:369) ip_send_skb (net/ipv4/ip_output.c:1508) udp_send_skb (net/ipv4/udp.c:1195) udp_sendmsg (net/ipv4/udp.c:1485) inet_sendmsg (net/ipv4/af_inet.c:859) __sys_sendto (net/socket.c:2206) Fix this by setting skb->dev = slave before calling netdev_start_xmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Use correct version for UAC3 header validation The entry of the validators table for UAC3 AC header descriptor is defined with the wrong protocol version UAC_VERSION_2, while it should have been UAC_VERSION_3. This results in the validator never matching for actual UAC3 devices (protocol == UAC_VERSION_3), causing their header descriptors to bypass validation entirely. A malicious USB device presenting a truncated UAC3 header could exploit this to cause out-of-bounds reads when the driver later accesses unvalidated descriptor fields. The bug was introduced in the same commit as the recently fixed UAC3 feature unit sub-type typo, and appears to be from the same copy-paste error when the UAC3 section was created from the UAC2 section.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix locking for bcm_op runtime updates Commit c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") added a locking for some variables that can be modified at runtime when updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup(). Usually the RX_SETUP only handles and filters incoming traffic with one exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcm_op uses bcm_can_tx() which uses the bcm_tx_lock that was only initialized in bcm_tx_setup(). Add the missing spin_lock_init() when allocating the bcm_op in bcm_rx_setup() to handle the RTR case properly.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them In commit 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference at raw event handle"), we handle the fact that raw event callbacks can happen even for a HID device that has not been "claimed" causing a crash if a broken device were attempted to be connected to the system. Fix up the remaining in-tree HID drivers that forgot to add this same check to resolve the same issue.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPL In DQ-QPL mode, gve_tx_clean_pending_packets() incorrectly uses the RDA buffer cleanup path. It iterates num_bufs times and attempts to unmap entries in the dma array. This leads to two issues: 1. The dma array shares storage with tx_qpl_buf_ids (union). Interpreting buffer IDs as DMA addresses results in attempting to unmap incorrect memory locations. 2. num_bufs in QPL mode (counting 2K chunks) can significantly exceed the size of the dma array, causing out-of-bounds access warnings (trace below is how we noticed this issue). UBSAN: array-index-out-of-bounds in drivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 index 18 is out of range for type 'dma_addr_t[18]' (aka 'unsigned long long[18]') Workqueue: gve gve_service_task [gve] Call Trace: <TASK> dump_stack_lvl+0x33/0xa0 __ubsan_handle_out_of_bounds+0xdc/0x110 gve_tx_stop_ring_dqo+0x182/0x200 [gve] gve_close+0x1be/0x450 [gve] gve_reset+0x99/0x120 [gve] gve_service_task+0x61/0x100 [gve] process_scheduled_works+0x1e9/0x380 Fix this by properly checking for QPL mode and delegating to gve_free_tx_qpl_bufs() to reclaim the buffers.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки

Описание

In the Linux kernel, the following vulnerability has been resolved: icmp: fix NULL pointer dereference in icmp_tag_validation() icmp_tag_validation() unconditionally dereferences the result of rcu_dereference(inet_protos[proto]) without checking for NULL. The inet_protos[] array is sparse -- only about 15 of 256 protocol numbers have registered handlers. When ip_no_pmtu_disc is set to 3 (hardened PMTU mode) and the kernel receives an ICMP Fragmentation Needed error with a quoted inner IP header containing an unregistered protocol number, the NULL dereference causes a kernel panic in softirq context. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:icmp_unreach (net/ipv4/icmp.c:1085 net/ipv4/icmp.c:1143) Call Trace: <IRQ> icmp_rcv (net/ipv4/icmp.c:1527) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207) ip_local_deliver_finish (net/ipv4/ip_input.c:242) ip_local_deliver (net/ipv4/ip_input.c:262) ip_rcv (net/ipv4/ip_input.c:573) __netif_receive_skb_one_core (net/core/dev.c:6164) process_backlog (net/core/dev.c:6628) handle_softirqs (kernel/softirq.c:561) </IRQ> Add a NULL check before accessing icmp_strict_tag_validation. If the protocol has no registered handler, return false since it cannot perform strict tag validation.


Затронутые продукты
Image SLES12-SP5-Azure-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-HPC-BYOS:kernel-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:cluster-md-kmp-default-4.12.14-122.299.1
Image SLES12-SP5-Azure-SAP-BYOS:dlm-kmp-default-4.12.14-122.299.1

Ссылки
Уязвимость SUSE-SU-2026:1668-1